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I .  INTRODUCTION 


In  March  of  1992,  two  Naval  Postgraduate  School  (NPS) 
students,  Nolan  J.S.  and  Youngblood  P.D.,  proposed  a  decision 
support  system  (DSS) ,  "NAVAL  POSTGRADUATE  SCHOOL  SCHEDULING 
SUPPORT  SYSTEM  (NPS4)  ",  to  assist  the  NPS  course  schedulers  in 
developing  student,  instructor,  room  and  final  exam  schedules 
for  an  academic  quarter.  (Nolan,  1992) 

Their  thesis  research  consisted  of  an  extensive  systems 
analysis  which  included  an  historical  study  of  the  evolution 
of  the  NPS  scheduling  process  and  an  examination  of  every 
detail  of  the  current  scheduling  system.  They  provided  a 
definition  of  scheduling  needs  and  requirements,  some  database 
specifications,  proposals  and  recommendations  to  develop  a  DSS 
and  the  evaluation  of  alternative  solutions.  Additionally,  a 
user  interface  prototype  was  presented.  (Nolan,  1992) 

In  NPS4,  Nolan  and  Youngblood  presented  a  number  of 
alternative  solutions  for  the  NPS  scheduling  process.  An 
analysis  of  their  research  reveals  the  following 
recommendations  common  to  the  majority  of  the  alternative 
solutions : 

•  augmentation  of  parts  of  the  existing  system  is  presumably 
the  most  prudent  option  in  terms  of  maintaining  the  human 
element  in  the  scheduling  process,  easing  user  transition 
into  a  new  system  and  holding  down  implementation  costs; 
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•  any  automated  portion  of  the  current  scheduling  system 
should  have  the  capability  to  accommodate  at  least  two 
course  schedulers,  offering  concurrent  access  and  use  of 
the  scheduling  data  and  partially  completed  schedules;  and 

•  a  dedicated  relational  database  is  needed  in  almost  all 
alternative  solutions  to  store  the  huge  amount  of 
important  information  (much  of  which  resides  on  the  NPS 
mainframe  computer)  required  to  construct  student  course 
group,  instructor  and  room  schedules.  (Nolan,  1992) 


A.  PROBLEM 

As  previously  mentioned,  Nolan  and  Youngblood  (1992) 
presented  a  user  interface  prototype  to  validate  the  course 
scheduler's  requirements.  This  was  accomplished  using  a  rapid 
prototyping  methodology  as  a  tool  for  software  development. 
However,  there  is  a  need  for  multiple  methodologies  in 
developing  large  systems  such  as  that  presented  by  the  NPS 
scheduling  process  (Keyes,  1992).  In  today's  changing  world 
of  software  development,  structured  analysis  and  design 
methods  can  be  integrated  with  prototyping  techniques 
(Keuffel,  March  1992),  "...coming  together  in  a  combination 
that  is  better  than  any  of  the  parts...."  (Keyes,  1992)  in 
order  to  shorten  the  system  development  life  cycle. 

The  purpose  and  goal  of  this  thesis  research  is  to  provide 
a  more  detailed  systems  analysis  and  design  specifications  of 
the  current  NPS  scheduling  process  and  the  target  system 
presented  and  proposed  respectively  by  Nolan  and  Youngblood  in 
NPS4.  We  envision  that  these  specifications  will  be  used  by 
computer  programmers  for  eventual  systems  implementation  of  a 
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computer  based  solution/enhancement  to  the  current  scheduling 
system  or  to  NPS4.  Structured  Systems  Analysis  and  Design 
methodologies  will  be  used  with  emphasis  on  database  design. 

B.  METHODOLOGY 

Semi- formal  analysis  and  design  specifications  will  be 
developed  using  dataflow  diagrams,  structure  charts  and  module 
specifications,  complemented  by  database  specifications 
consisting  of  entity  relationship  diagrams  and  entity  and 
attribute  definitions. 

C.  STRUCTURE  OP  THIS  THESIS 

Chapter  II  provides  a  brief  discussion  of  the  organization 
of  the  Naval  Postgraduate  School  and  the  background  of  the 
current  NPS  course  scheduling  process. 

Chapter  III  presents  a  concise  overview  of  dataflow 
diagrams,  entity  relationship  diagrams,  structure  charts  and 
module  specifications. 

Chapter  IV  summarizes  the  conclusions  and  recommendations 
for  follow-on  steps  required  to  implement  the  design  generated 
in  this  thesis. 
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Appendices  A,  B,  C,  D  and  E  contain  the  physical  dataflow 
diagrams  of  the  current  NPS  scheduling  system,  the  entity 
relationship  diagrams  with  related  entity  and  attribute 
definitions,  the  logical  dataflow  diagrams  of  the  target 
scheduling  system,  the  target  system  structure  charts,  and  the 
module  specifications,  respectively. 
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II.  BACKGROUND  ON  NPS  SCHEDULING 


A.  NAVAL  POSTGRADUATE  SCHOOL  (NPS) 

The  Naval  Postgraduate  School  is  atypical  compared  to  most 
public  and  private  academic  institutions  with  respect  to  its 
course  scheduling  process.  For  the  sake  of  clarity,  a  brief 
description  of  the  NPS  scheduling  process  summarized  from 
Nolan  and  Youngblood  (1992)  is  presented  below: 

Under  the  auspices  of  the  Chief  of  Naval  Operations,  the 
Naval  Postgraduate  School  located  at  Monterey,  California,  is 
an  academic  institution  of  higher  learning  and  research  with 
the  primary  purpose  to  increase  the  combat  effectiveness  of 
U.S.  and  allied  armed  forces  by  providing  graduate  degree 
programs  to  qualified  students  in  areas  not  usually  available 
through  other  educational  institutions,  and  by  conducting 
research  that  actively  supports  U.S.  armed  forces  operations. 
(Nolan,  1992) 

The  student  body  at  NPS  is  composed  of  U.S.  military 
officers  from  all  branches  of  the  service,  foreign  national 
officers  from  almost  30  allied  countries,  and  some  U.S. 
military  enlisted  personnel  and  federal  civilian  employees. 
Most  study  and  research  programs  pursued  satisfy  both  Masters 
or  Doctorate  degree  requirements  and  fulfil  requirements  that 
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earn  a  military  occupational  specialty  (MOS)  code  for  service 
members.  (Nolan,  1992) 

The  NPS  administration  of  learning  and  research  is  a 
cooperative  effort  between  military  and  civilian  personnel. 
Academic  departments,  with  a  majority  of  their  faculty  members 
being  civilians  with  Doctorate  degrees,  prepare  and  offer 
courses.  Curricular  programs  of  study  are  developed  by 
military  Curricular  Officers,  who  direct  students  through 
chosen  programs  to  ensure  students  complete  both  degree  and 
MOS  requirements.  Civilian  Academic  Associates  work  with 
Curricular  Officers  to  ensure  that  each  curricular  program  is 
academically  sound.  A  civilian  Management  Analyst  manages 
the  collection  of  Departmental  and  Curricular  Officer  data 
used  in  the  scheduling  process,  and  the  NPS  Class  Schedulers 
construct  course  schedules  from  this  collected  data.  (Nolan, 
1992) 

B.  CURRENT  NPS  COURSE  SCHEDULING 

The  academic  year  at  NPS  is  divided  into  four  quarters, 
Fall,  Winter,  Spring  and  Summer.  The  scheduling  process 
consists  of  four  phases  and  requires  a  joint  effort  from 
several  groups  of  people  in  order  to  construct  schedules 
during  each  quarter.  An  excerpt  from  NPS4  (Nolan,  1992) 
summarizes  the  four  phases  of  the  scheduling  process  at  NPS: 
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1.  Forecasting 

Up  to  a  year  or  more  in  advance,  departmental 
schedulers  and  the  Management  Analyst  forecast  probable 
quarterly  student  course  demands  and  Instructor  workloads 
necessary  to  meet  these  demands.  A  Tentative  Course  Schedule 
is  produced  indicating  which  courses  are  expected  to  be  taught 
by  each  academic  department  during  each  quarter.  (Nolan, 
1992) 

2 .  Pr e - Schedul ing 

Pre- Scheduling  is  a  quarterly  process.  Curricular 
Officers,  via  the  Management  Analyst,  give  departmental 
schedulers  information  about  which  courses  their  students  are 
requesting  for  that  quarter.  Departments  then  determine  which 
courses  will  actually  be  taught  that  quarter.  If  there  are 
requested  courses  that  will  not  be  taught,  students  replace 
these  v.*ith  ones  that  will  be.  After  receiving  this  updated 
information,  departments  divide  courses  that  are  too  large 
into  segments  and  assign  instructors  to  teach  each  course. 
(Nolan,  1992) 

3 .  Scheduling 

Pre -Schedul ing  information  is  given  to  the  Class 
Schedulers,  who  use  it  to  construct  a  Master  Instruction 
Schedule  and  individual  schedules  for  students,  instructors 
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and  classrooms.  Schedules  for  the  upcoming  quarter  are  then 
distributed  to  applicable  offices  and  individuals.  (Nolan, 
1992) 

4.  Post- Scheduling 

After  all  the  schedules  are  constructed  including  the 
Master  Instruction  Schedule,  and  throughout  the  scheduled 
quarter,  changes  may  be  made  to  the  student,  Instructor  or 
room  schedules.  Student  schedule  changes  are  approved  by 
their  Curricular  Officer  and  Academic  Associate.  Instructor 
schedule  changes  to  a  course's  room  or  time  periods  are 
coordinated  by  the  Class  Schedulers  and  the  changes  are 
registered  and  maintained  by  them.  (Nolan,  1992) 

5.  Synopsis  o£  the  Present  Situation 

Each  quarter  during  the  scheduling  phase,  course 
scheduling  is  done  entirely  by  manual  manipulation  of 
information  from  Department  Chairmen  and  Curricular  Officers 
by  two  Class  Schedulers.  The  Schedulers,  with  pencil  and  5" 
x  8"  schedule  cards  use  "time-proven  heuristics,"  (Nolan, 
1992)  to  assign  time  periods  and  rooms  literally  by  hand  to 
hundreds  of  courses  and  course  segments  offered  during  a 
quarter.  These  courses  and  course  segments  are  then  matched 
to  approximately  300  Instructor  schedules  and  1100  student 
course  group  schedules.  Additionally  each  quarter,  room 
schedules  for  each  academic  room  used  for  instruction  at  NPS, 
are  manually  generated.  (Nolan,  1992) 
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Course  Schedulers  use  a  set  of  scheduling  priority 
guidelines,  as  well  as  Instructor  preferences  taken  from 
Department  Chairman  Reports,  to  help  minimize  scheduling 
conflicts.  However,  when  conflicts  do  occur,  such  as  time 
period  and/or  room  conflicts,  or  changes  in  course  scheduling 
are  requested,  each  conflict  or  change  request  is  manually 
resolved,  subsequently  changing  each  schedule  card  affected. 
(Nolan,  1992) 

In  addition  to  the  original  schedule  cards  that  are 
constructed  each  quarter,  each  original  schedule  is 
photocopied  multiple  times  and  distributed  to  their  respective 
recipients . 

After  regular  course  scheduling  is  completed,  final 
exam  schedules  must  be  constructed  for  each  course  that 
requires  a  final  exam,  assigning  rooms  and  time  periods  to 
each  final  exam.  As  with  regular  course  scheduling,  conflicts 
must  be  minimized,  resolved  and  avoided. 

The  present  scheduling  process  at  the  time  of  this 
thesis  research  is  seen  as  being  vastly  inefficient  in  regard 
to  spending  valuable  man-hours  making  tedious  manual  entries 
and  erasures  to  schedules  and  their  related  schedules,  and 
photocopying  thousands  of  schedule  cards  for  distribution. 

6.  Most  Pressing  Concerns 

Thesis  research  done  by  Nolan  and  Youngblood  (1992)  in 
"The  Naval  Postgraduate  School  Scheduling  Support  System, " 
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identified  the  most  pressing  concerns  regarding  the  current 
NPS  scheduling  process: 


•  "...constantly  having  to  locate,  retrieve,  and  replace 
physical  schedule  cards...."  (Nolan  1992)  related  to  each 
scheduled  course  and  course  segment  in  order  to  add, 
modify  or  delete  schedule  information; 

•  "...lack  of  standardization  in  department  entries  to  the 
[final]  iteration  of  the  Department  Chairman  Report...." 
(Nolan,  1992)  indicating  whether  time  periods  and  rooms 
are  required  or  preferred  by  instructors;  and 

•  lack  of  proper  documentation  methodology  for  changes  to 
schedules  during  the  Post -Scheduling  phase.  (Nolan,  1992) 

In  their  analysis,  Nolan  and  Youngblood,  emphasized 
the  need  to  maintain  the  human  element  required  in  the  complex 
scheduling  construction  at  NPS,  and  allowing  the  continuation 
of  the  freedoms  of  choice  enjoyed  in  the  present  scheduling 
process.  Since  maintaining  the  human  element  is  paramount  in 
any  given  solution  to  meet  the  scheduling  system  requirements 
at  NPS,  Nolan  and  Youngblood  proposed  a  partly  automated 
decision  support  system,  extending  the  present  scheduling 
system  capacity  and  creating  more  system  capabilities. 
(Nolan,  1992) 

C.  NAVAL  POSTGRADUATE  SCHOOL  SCHEDULING  SYSTEM  (NPS3) 

1.  Function 

A  database  management  system,  the  Naval  Postgraduate 
School  Scheduling  System  (NPS3)  is  proposed  to  support  the  NPS 
course  schedulers  in  scheduling  academic  events  and  courses 
for  students,  instructors  and  classrooms  during  an  academic 
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quarter.  NPS3  is  designed  to  assist  schedulers  in  the 
scheduling  process  by  presenting  courses  to  be  scheduled  based 
on  scheduling  priorities  (Nolan,  1992)  .  Semi -permanent  events 
are  automatically  scheduled  and  entered  in  relevant  student, 
instructor  and  room  schedules  based  on  predetermined  entries 
in  the  NPS3  database.  Schedulers  are  allowed  to  assign  time 
periods  and  classrooms  to  each  subsequent  course,  course 
segment  or  laboratory.  After  resolving  any  scheduling 
conflicts,  NPS3  then  enters  the  scheduling  information  in  the 
appropriate  student,  instructor  and  room  schedules  before  the 
next  course,  course  segment  or  laboratory  is  scheduled.  This 
process  continues  until  the  lowest  priority  course  is 
scheduled.  (Interview,  Schedulers,  April  13,  1992) 

2.  Extending  NPS4 

Nolan  and  Youngblood  (1992)  used  a  rapid  prototyping 
strategy  during  the  analysis  phase  of  system  development 
demonstrating  a  user  interface  prototype  "...to  validate  the 
analyst's  view  of  what  the  user's  want  and  need.  ..."  (Keuffel, 
October  1991) .  This  user  interface  prototype  was  developed 
"...using  HyperCard  2.0  on  an  Apple  Macintosh  Ilci  personal 
computer  with  8MB  of  RAM  and  a  64K  cache  card  under  the  System 
7  operating  system."  (Nolan,  1992) 
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There  are  limitations  to  using  rapid  prototyping  in 
systems  development:  it  is  "...hard  to  control,  and  has  no 
overall  plan,  intermediate  deliverables,  'audit  trail,'  or 
certainty  about  the  result".  (Gardner,  1991) 

Furthermore,  using  Apple  Macintosh's  HyperCard 
environment  to  develop  a  scheduling  system  for  the  NPS  course 
schedulers  presents  a  dilemma.  Currently,  NPS  course 
schedulers  operate  in  an  IBM  compatible  PC  environment,  making 
the  use  of  HyperCard  for  continuation  in  system  development 
questionable. 

Given  the  limitations  of  rapid  prototyping,  the 
incompatibility  dilemma  that  HyperCard  presents,  and  the 
enormity  of  the  NPS  scheduling  process,  a  need  exists  for 
structured  analysis  and  design  documentation  of  the  Naval 
Postgraduate  School  Scheduling  System  (NPS3)  . 

Structured  methodologies  provide  "...guidance  in 
completing  complex  tasks  as  well  as  providing  a  medium  for 
consistent  communication...."  (Gardner,  1991)  between 
analysts,  designers  and  programmers.  "Methodologies  are  based 
on  theory  and  have  been  tested  many  times,  so  that  they've 
acquired  formal  rigor."  (Gardner,  1991)  In  addition, 
structured  methodology  offers  an  historical  record  of  the 
system  under  development  (Keuffel,  March  1992) . 

NPS3  is  not  intended  to  replace  the  work  done  by  Nolan 
and  Youngblood  (1992)  ,  but  to  be  used  to  complement  their  work 
in  an  integrated  and  interactive  approach  to  the  system 
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development.  NPS3  will  facilitate  communication  between 
system  development  team  members  by  partitioning  the  scheduling 
process  "...  into  manageable  chunks...."  (Plauger,  1992).  The 
scheduling  process  problem  is  "...decomposed  into  parts...." 
showing  the  "...modularity  of  design...."  presenting  "...a 
logical  design  before  one  tries  the  physical  design. " 
(Gardner,  1991).  NPS3  will  answer  questions  such  as: 

•  Where  is  the  development  process  now?, 

•  What  development  has  been  accomplished  to  date?,  and 

•  Where  is  the  development  process  going  next? 

Moreover,  addressing  the  HyperCard  dilemma,  NPS3 
structured  analysis  and  design  specifications  will  be 
developed  "...to  achieve  hardware  and  software 

independence...."  (Wetherbe,  1984).  In  doing  so,  NPS3  allows 
future  system  implementors  the  freedom  to  choose  the 
appropriate  hardware  and  software  for  system  implementation. 

3.  Concurrent  Access  of  Data 

An  issue  not  addressed  in  the  NPS3  design 
specifications,  but  certainly  important  in  developing  a 
multiuser  database  scheduling  system,  is  the  need  for 

concurrent  access  and  use  of  scheduling  data  and  partially 
completed  schedules. 

When  the  situation  arises  where  two  or  more  schedulers 
are  using  the  same  scheduling  data  and/or  partially  completed 
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schedules  (e.g.,  two  different  schedulers  are  scheduling  two 
different  courses  to  the  same  instructor  schedule) ,  a  certain 
degree  of  data  and  record  locking  is  needed  while  at  the  same 
time  allowing  for  the  'refreshing  '  of  the  concurrent 
scheduler's  screen  as  one  scheduler  manipulates  data  shared  by 
both  schedulers. 

Care  must  be  taken  to  ensure  that  there  is  not  too 
little  data  or  record  locking  which  may  cause  integrity 
problems,  nor  too  much  data  or  record  locking  which  may  result 
in  delays  or  deadlock.  (PC  User,  June  17,  1992)  Furthermore, 
the  time  taken  to  'refresh'  a  scheduler's  screen  is  a  critical 
factor  in  the  efficiency  of  the  scheduling  system.  If  not 
done  properly,  one  scheduler  could  effectively  update/erase  an 
other  scheduler's  recent  changes  to  the  concurrent  data  and/or 
schedule. 

To  account  for  'refreshing'  a  scheduler's  screen,  NPS3 
structure  charts  would  have  to  be  modified.  The  most  logical 
place  to  'refresh'  a  scheduler's  screen  is  during  the 
procedure  for  resolving  schedule  record  conflicts,  Appendix  D, 
Figure  D-22.  When  the  system  determines  schedule  conflicts, 
searches  for  alternative  schedule  selections,  or  puts 
alternative  selection  to  the  schedule  record,  multiuser 
screens  accessing  concurrent  data  and/or  schedules  can  be 
checked  and  'refreshed'  with  the  relevant  scheduling  data 
where  appropriate. 
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III.  STRUCTURED  METHODOLOGY 

Structured  methods  provide  an  effective  " . . .communication 
vehicle...."  (Keyes,  1992)  for  analysts  to  capture  the  system 
requirements  from  its  end  users  (Keuffel,  March  1992)  and 
provide  traceability  and  maintainability  to  programmers  during 
system  design  and  implementation  (Riehle,  1991) .  The 
structured  methodologies  used  in  this  thesis  are  structured 
analysis,  entity  relationship  diagrams  and  structured  design. 
The  structured  analysis  includes  physical  and  logical  data 
flow  diagrams.  Entity  and  attribute  definitions  are  included 
with  the  entity  relationship  diagrams.  The  structured  design 
includes  structure  charts  and  module  specifications. 

A.  DATA  FLOW  DIAGRAMS 

Dataflow  diagrams  (DFD)  are  models  used  widely  in 
structured  analysis.  They  are  not  flow  charts  and  thus  do  not 
explicitly  show  the  flow  of  control  through  a  system. 
However,  dataflow  diagrams  do  show  flow  of  data,  storage  of 
data,  and  the  processes  that  respond  to  and  change  data. 
(Whitten,  1989) 

Different  language  and  symbol  sets  have  been  developed  to 
illustrate  dataflow  diagrams.  For  the  purposes  of  this 
thesis,  and  illustrated  in  Figure  3.1,  the  Demarco- Yourdon 
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symbol  set,  "...perhaps  the  most  well  known...."  (Keyes, 
1992),  will  be  used  where: 


•  A  circle  represents  a  process  that  transforms  inputs  into 
outputs.  The  details  of  the  process  are  not  known. 

•  A  rectangle  depicts  a  source/destination  name  that  defines 
the  boundaries  of  the  system.  Source/destinations  provide 
the  net  inputs  to  and  receive  the  net  outputs  from  the 
system. 

•  Data  stores  are  depicted  as  open-ended  boxes. 

•  Named  arrows  are  depicted  as  data  flows,  representing 
inputs  or  outputs. 

•  A  slash  in  the  lower  right-hand  corner  of  a 
source/destination  indicates  a  repetition  of  a 
source/destination  within  the  given  data  flow  diagram. 

•  A  double  line  to  the  left  of  a  data  store  indicates  that 
a  data  store  is  repeated  within  the  given  data  flow 
diagram.  (Whitten,  1989) 


Figure  3.1  Data  flow  diagram  notation 


Several  sets  of  dataflow  diagrams  are  produced  during 
structured  analysis  and  include  DFD's  that: 


•  Model  the  current  system  and  the  target  system  to  be 
built . 


•  Model  the  physical  implementation  details  of  the  system, 
called  the  physical  system,  or  model  the  essential 
characteristics  of  the  system,  called  the  logical  system. 
(Whitten,  1989) 

In  Appendix  A,  the  physical  context  data  flow  diagrams  and 
the  physical  systems  level  data  flow  diagrams  for  the  current 
NPS  scheduling  process  are  presented  to  detail  the  current 
scheduling  system  implementation. 

In  an  attempt  to  gain  a  more  detailed  description  of  the 
NPS  scheduling  process  user  requirements  presented  by  Nolan 
and  Youngblood  (1992) ,  and  to  enhance  possible  alternative 
implementation  solutions,  the  logical  data  flow  diagrams  are 
displayed  in  Appendix  C.  The  logical  data  flow  diagrams  model 
the  essential  processing  requirements  of  the  system 
independent  of  any  technology  that  might  be  used  to  implement 
those  requirements  (Whitten,  1989) . 

B.  ENTITY  RELATIONSHIP  DIAGRAMS 

An  Entity  Relationship  Diagram  (ERD)  is  a  logical  systems 
analysis  technique  of  data  modeling  that  illustrates  "...data 
at  rest...."  (Whitten,  1989).  An  ERD  is  a  very  detailed 
picture  of  data  storage  independent  of  the  processing 
performed  with  those  data  stores.  Therefore  ERD's  do  not 
depict  flow  or  processing  of  data  and  should  not  be  read  like 
data  flow  diagrams  or  flow  charts.  Because  entity 
relationship  diagrams  depict  data  at  rest  or  data  being 
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stored,  they  do  not  imply  how  data  is  implemented,  created, 
modified,  used  or  deleted.  (Whitten,  1989) 

An  ERD  is  made  up  of  entities  and  the  relationships 
between  those  entities.  An  entity  is  anything  real  or 
abstract  that  can  be  described  by  a  set  of  common 
characteristics  that  are  called  data  elements  or  attributes. 
Usually,  at  least  one  of  the  entity's  data  elements  uniquely 
identifies  one  and  only  one  occurrence  of  the  entity.  This 
data  element  or  elements  is  referred  to  as  the  key.  (Whitten, 
1989) 

A  relationship  is  a  natural  association  between  one  or 
more  entities.  Relationships  usually  exist  between  two 
different  entities,  but  may  also  exist  between  different 
occurrences  of  the  same  entity.  Furthermore,  relationships 
may  be  dependent  on  other  relationships.  (Whitten,  1989) 

As  with  data  flow  diagrams,  various  language  and 
symbology  is  used  to  illustrate  entity  relationship  diagrams, 
see  Figure  3.2.  Normally  a  rectangle  represents  an  entity 
while  a  diamond  represents  a  relationship.  Because  of  the 
complexity  of  the  NPS  scheduling  process  and  its  many  entities 
and  relationships,  the  diamond  is  omitted  to  save  space  in  the 
NPS  Scheduling  System  ERD.  (Whitten,  1989) 
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Entity  A  has  ura  or  nora  ra tat  ioitalt  1  pa  with  Entity  I. 
while  Entity  ■  will  alwaya  hava  ona  r •  1  a t  i  onah  1  p  with 
Entity  A  . 


Figure  3 . 2  One-to-many  entity  relationship  diagram  notation 


The  NPS  Scheduling  System  entity  relationships  are 
described  by  words  and  symbols  that  indicate  the  number  of 
occurrences  of  one  entity  that  can  exist  for  a  single 
occurrence  of  the  related  entity,  and  vice  versa.  Three 
general  possibilities  of  occurrences  exist: 


•  One-to-one  (1:1) --for  one  occurrence  of  the  first  entity 
there  can  exist  only  one  related  occurrence  of  the  second 
entity  and  vice  versa; 

•  One-to-many  (l:M  or  M:l)  -  -for  one  occurrence  of  one  entity 
there  can  exist  many  related  occurrences  of  a  second 
entity;  it  doesn't  matter  which  is  first  or  second; 


•  Many-to-many  (M:M)--for  one  occurrence  of  the  first  entity 
there  exists  many  related  occurrences  of  the  second 
entity,  and  for  one  occurrence  of  the  second  entity  there 
exists  many  occurrences  of  the  first  entity.  Many- to  many 
relationships  are  transformed  into  one-to-many 
relationships  creating  an  intersection  between  the  many- 
to-many  relationship.  (Whitten,  1989) 

Furthermore,  the  hash  marks  on  the  line  between  a 
relationship  represent  a  mandatory  relationship  while  a  circle 
represents  an  optional  relationship  (Kroenke,  1988)  .  A 
"...crow's  foot...."  (Haas,  1991)  on  a  line  between  a 
relationship  represents  many  occurrences  of  that  relationship 
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while  the  absence  of  a  "...crow's  foot...."  (Haas,  1991) 
represents  one  occurrence  of  that  relationship. 

Appendix  B  presents  the  Entity  Relationship  Diagrams  and 
the  entity  and  attribute  definitions  for  the  proposed  NPS 
Scheduling  System. 

C.  STRUCTURED  DESIGN  USING  STRUCTURE  CHARTS 

Structured  design  is  considered  a  disciplined  approach  to 
computer  design  that: 

•  develops  ". . .a  blueprint  of  a  computer  system  solution  to 
a  problem  that  has  the  same  components  and 
interrelationships  among  the  components  as  the 
original  problem. . . . 

•  ...  seeks  to  conquer  the  complexity  of  large  systems  by 
means  of  partitioning  the  system  into  'black  boxes',  and 
by  organizing  the  black  boxes  into  hierarchies  suitable 
for  computer  implementation.... 

•  [and]  ...uses  tools,  especially  graphic  ones,  to  render 
systems  readily  understandable."  (Page- Jones,  1988) 

In  Structured  Design,  structure  charts  are  used  to 
illustrate  the  partitioning  of  a  system  into  modules,  or 
'black  boxes' ,  and  show  their  hierarchy,  organization  and 
communication.  The  concern  is  almost  entirely  with  what  a 
module  does  rather  than  how  it  does  it.  This  form  of 
documentation  actually  helps  the  designers  during  the  design 
effort.  (Page-Jones,  1988)  Structure  charts  present  a 
"...template  for  coding.... a  plan  of  attack...."  (Keuffel, 
October  1991) ,  bridging  the  gap  between  the  analysis  and  the 
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design  of  a  system.  Furthermore,  structure  charts  are 
flexible  enough  to  remain  current  with  modification  to  the 
system  over  its  lifetime.  (Page-Jones,  1988) 

In  addition,  these  structure  charts  serve  as  a  'road  map' 
for  maintainers  to  use  to  quickly  track  down  defects  or 
implement  user  modifications.  (Page-Jones,  1988) 

Figure  3.3  illustrates  structure  chart  notation.  Modules 
are  shown  as  rectangular  boxes,  with  their  names  inside.  The 
name  is  a  statement  of  the  module's  function,  what  it  does  to 
completion  each  time  it  is  called.  Pre-defined  modules  are 
graphically  illustrated  by  adding  lines  parallel  to  its 
vertical  sides.  Pre-defined  modules  already  exist  in  a  system 
or  application  library,  operating  system  or  database 
management  system.  Communication  from  one  module  to  another, 
referred  to  as  a  'call',  is  indicated  by  an  arrow.  Data  that 
flows  between  modules  is  illustrated  by  using  a  circle  with  an 
arrow  attached.  (Page-Jones,  1988) 
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Figure  3.3  Structure  chart  notation 


By  using  the  scheduling  system  requirements  detailed  by 
Nolan  and  Youngblood  (1992),  and  the  specifications  from 
Appendix  C,  Appendix  D  presents  the  NPS3  structure  charts 
illustrating  the  use  of  a  database  management  system: 

•  to  automatically  import  data  from  files  downloaded  from 
the  NPS  mainframe  computer, 

•  to  allow  the  user  to  update  existing  NPS3  database  files, 

•  to  create  NPS  schedules  by  allowing  users  to  schedule 
courses  based  on  scheduling  priorities,  and 

•  to  review  and  update  existing  schedule  files. 

D .  MODULE  SPECIFICATIONS 

Like  structure  charts,  module  specifications  are  used  as 
a  communication  tool  to  bridge  the  gap  between  design  and 
programming,  giving  a  potential  programmer  information  on  the 
procedural  details  of  each  module.  The  programmer  is  told 
what  inputs  the  module  uses  when  called,  what  outputs  the 
module  returns  and  the  function  the  module  is  expected  to 
carry  out.  (Page -Jones,  1988) 

Two  types  of  specifications  are  offered:  interface 
specifications  and  specification  by  pseudocode.  Interface 
specifications  use  structured  English,  providing  " . .  .a  minimal 
amount  of  procedural  detail  to  accompany  the  structure  chart." 
(Page- Jones,  1988)  This  allows  the  programmer  the  freedom  to 
program  in  what  ever  way  he/she  pleases. 


22 


Specification  by  pseudocode  is  a  more  detailed 
description  of  a  module's  internal  procedure.  Pseudocode 
simulates  actual  code  and  therefore  presents  less  work  for  the 
programmer  to  attain  the  final  code.  (Page- Jones,  1988) 

Appendix  E  provides  the  module  specifications  for  the  NPS3 
modules  illustrated  in  Appendix  D. 
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IV.  CONCLUSION/RECOMMENDATION 


A.  WHY  STRUCTURED  METHODOLOGY? 

The  Naval  Postgraduate  School  Scheduling  System  (NPS3) 
detailed  in  this  thesis  does  not  pretend  to  offer  a  fool  proof 
analysis  and  design  solution  to  the  NPS  course  scheduling 
process.  However,  NPS3  is  presented  to  reinforce  and 
complement  the  work  done  by  Nolan  and  Youngblood  (1992)  by 
suggesting  a  structured  rational  design  approach. 

A  structured  rational  design  approach  to  system 
development  will  offer  understanding  and  guidance  to  potential 
programmers,  facilitate  control  of  the  project  rather  than 
proceed  in  an  adhoc  manner,  present  a  standard  procedure  for 
system  implementation,  make  measuring  the  progress  of  a  system 
easier  and  enhance  good  overall  management  of  the  system 
development.  (Keuffel,  September  1991) 

To  expedite  the  growth  of  the  scheduling  system,  NPS3 

structured  analysis  and  design  specifications  and  Nolan  and 

Youngblood's  (1992)  user  interface  prototype  "...can  be 

integrated  into  a  new  development  life  cycle  that  combines  the 

benefits  of  both  approaches...."  (Plauger,  1992). 

"From  structured  methods,  we  gain  the  abstract 
representation  of  the  system  and  the  documentation  that 
provides  the  historical  record  of  the  project.  From  rapid 
prototyping  we  gain  the  ability  to  quickly  put  before  our 
users  a  concrete  representation  of  user  interfaces,  which 
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iteratively  evolves  into  the  completed  system."  (Keuffel, 
March  1992) 

B .  IMPLEMENTATION 

A  system  with  the  size  and  complexity  of  the  Naval 
Postgraduate  School  Scheduling  System  can  be  implemented  in  a 
number  of  different  ways. 

The  first  step  that  should  be  taken  for  implementation  is 
to  build  the  relational  database  management  system  given  the 
specifications  in  Appendix  B.  Once  the  relational  database  is 
built,  integration  with  Nolan  and  Youngblood's  user  interface 
prototype  should  be  investigated  to  incorporate  the  relational 
database  and  the  user  interface  prototype  into  a 
"...functional  prototype...."  (The  Computer  Conference 
Analysis  Newsletter,  April  15,  1992) .  This  would  entail 
actually  building  part  of  the  scheduling  system.  It  is 
important  to  keep  in  mind  that  the  NPS  course  schedulers 
should  be  included  early  and  continually  in  the  implementation 
and  testing  of  the  scheduling  system. 

The  next  step  of  implementation  would  be  to  divide  the 
design  presented  in  this  thesis  into  logical  components  to  be 
developed  incrementally.  Possible  divisions  of  the  system 
are: 

•  a  component  to  read  files  downloaded  from  the  NPS 
mainframe  and  import  the  data  into  the  NPS3  database 
files ; 
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•  a  component  that  automatically  schedules  semi -permanent 
events  to  the  appropriate  schedules; 

•  a  component  that  allows  scheduling  of  courses  based  on  a 

particular  course  scheduling  priority,  after  which 

subsequent  priorities  could  easily  be  implemented; 

•  a  component  that  determines  and  resolves  any  scheduling 
conflicts  that  may  occur; 

•  a  component  that  'refreshes'  multiuser  screens  when 
concurrent  access  and  use  of  scheduling  data  and  partially 
completed  schedules  is  taking  place;  and 

•  although  not  addressed  in  this  thesis  except  to  show  their 
organization  in  the  overall  system,  components  for  the 
Final  Exam  Scheduling,  Master  Instruction  Schedule  and 
Scheduling  Data  Graph  applications,  respectively. 

C.  SOFTWARE 

There  are  a  number  of  PC-based  multiuser  relational 
database  management  systems  (RDBMS)  on  the  market  today  that 
would  be  possible  candidates  for  use  in  NPS3: 


•  Borland  International  Inc.'s  dBase  IV  1.5 

•  Borland  International  Inc.'s  Paradox  4.0; 

•  Fox  Software's  FoxPro  LAN  2.0; 

•  DataEase  International  Inc.'s  DataEase  4.5; 

•  Microrim  Inc.'s  R: BASE  3.1c; 

•  Oracle  Corp.'s  Oracle  7.0;  and 

•  Blyth  Software  Inc.'s  Omnis  7. 


Each  of  the  RDBMS's  listed  above  has  its  strengths  and 
weaknesses  relative  to  the  other  software  packages.  Although 
this  is  valuable  information  when  presenting  alternatives,  to 
give  a  detailed  analysis  of  the  strengths  and  weaknesses  of 
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each  RDBMS  would  be  a  thesis  in  itself.  Instead,  the 
following  major  considerations  are  provided  for  selecting  a 
multiuser  RDBMS: 


•  Ready- to -use -tools- -can  a  non -programmer  produce  adhoc 
queries  and  reports,  create  and  maintain  tables  and 
indexes,  and  enter  and  edit  data  without  custom  coding?; 

•  Database  maintenance- -  can  the  data  be  stored  and  accessed 
independent  of  any  application?; 

•  Environment- -does  the  RDBMS  offer  the  development 
environment  with  the  capability  to  produce  the  application 
needed  to  use  the  RDBMS  in  an  effective  manner?; 

•  Database  structure- -significant  restrictions  on  the  number 
of  records  or  fields  or  the  size  of  records  or  fields 
should  be  evaluated;  are  null  values  represented  correctly 
and  can  they  be  tested  for  in  the  database?;  is  the  data 
stored  in  one  large  repository  which  would  cause 
efficiency  problems  or  are  the  tables  stored  as  separate 
files  which  would  speed  data  access; 

•  Referential  integrity- -does  the  RDBMS  automatically 
prevent  erroneous  data  entries  to  records  that  don't  exist 
or  prevent  deletion  of  an  entity  record  without  deleting 
it  from  its  related  entities;  or  does  this  function  have 
to  be  programmed  in  by  the  user? ; 

•  Data  security  and  access  control- -what  degree  of  security 
and  access  control  is  offered?;  is  it  at  the  level 
needed? ;  will  you  have  to  write  code  to  get  it  to  the 
level  you  desire?; 

•  Record  locking- -this  was  addressed  in  Chapter  II  under 
Concurrent  Access  of  Data; 

•  Data  loading- -can  the  RDBMS  import  data  from  other  files 
or  databases?;  What  file  formats  can  it  read  and  how 
many?;  is  the  data  validated  before  or  after  loading?; 

•  Structured  Query  Language  supportability- -does  the  RDBMS 
support  embedded  SQL  for  executing  non -procedural 
operations  on  the  data  for  ease -of -access,  scaleability 
and  optimization; 
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•  Programming- -how  easy  is  it  to  customize  the  code  to  meet 
the  requirements  of  specific  applications?  (PC  User,  June 
17,  1992) ;  and 

•  HyperCard  interface- -the  RDBMS  must  have  the  capability  to 
either  provide  a  graphical  user  interface  (GUI)  as 
proposed  by  Nolan  and  Youngblood  (1992) ,  or  else  be  able 
to  connect  to  the  HyperCard  GUI  developed  in  NPS4 . 

D.  OMNIS  7 

In  the  author's  view,  Blyth  Software  Inc.'s  Omnis  7  is  a 
particularly  desirable  candidate  for  a  relational  database 
management  system  to  be  used  in  NPS3 . 

Although  relatively  high  priced  ($1,250),  Blyth  Software' s 
Omnis  7  offers  a  powerful  relational  database  management 
system  for  single  users  or  for  multiusers  of  complex  networked 
database  systems.  Specif ically  marketed  for  developers,  Omnis 
7  is  easy-to-use  and  robust  providing  abundant  features  for 
beginners  such  as  quick  prototyping,  a  short  popup  menu  mode 
that  "...generates  entry  screens,  reports,  and  menus  at  the 
click  of  a  mouse. ..."  (Miley,  1992) ,  and  " . . .online  context 
sensitive  help...."  (Fogel,  1992). 

Written  in  a  high  level  procedural  language,  C++,  Omnis  7 
lets  the  developer/user  take  care  of  several  discrete  steps  by 
issuing  a  single  command.  In  short,  Omnis  7  offers  "...a 
sophisticated  integrated  development  environment  for  creating 
database  applications...."  (Anderson,  1992). 
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One  of  the  features  that  make  Omnis  7  a  true  integrated 
development  environment  is  its  cross-platform  architecture. 
Omnis  7 

"...offers  seamless  portability  between  Mac  database 
applications  created  for  use  in  the  Mac  environment  and 
applications  meant  for  one  of  the  competing  PC-based 
graphical  user  environments,  Microsoft  Windows  or  IBM's 
Presentation  Manager.  Applications  written  for  Omnis 
Seven  on  any  of  these  platforms  can  be  moved  to  the  other 
without  modification."  (Miley,  1992) 

This  cross -platform  portability  makes  Omnis  7  a  perfect 
candidate  to  be  integrated  with  Nolan  and  Youngblood's  (1992) 
user  interface  prototype.  Alternatively,  Omnis  7  can  be 
developed  as  a  file  server  based  data  manager  in  a  LAN 
environment  or  "...as  a  front  end  to  a  Structured  Query 
Language  based  server...."  (Fogel,  1992).  Omnis  7  has  the 
capability  to  read  several  different  file  formats  facilitating 
the  importation  of  data  from  other  programs,  foreign  files  or 
databases  (Blyth  Software,  1990) . 

Omnis  7 '  s  database  engine  allows  dozens  of  files  to  be 

open  simultaneously,  can  display  fields  from  multiple  files  on 

a  single  window  and  can  update  all  open  files  with  a  single 

command.  In  addition,  Omnis  7  offers 

"...one  of  the  most  powerful  GUI  builders  in  the  industry. 

To  create  a  data  entry  window,  the  developer  paints  it  in 
design  mode,  and  Omnis  7  makes  it  come  alive  in  execute 
mode.  Aside  from  data -entry  fields,  virtually  any 
standard  GUI  element,  such  as  push  buttons,  check  boxes, 
and  scrolling  lists,  can  be  incorporated  into  an  Omnis  7 
window.  What's  more,  multiple  windows  can  be  open 
simultaneously,  each  one  movable,  scrollable  and  sizeable, 
and  each  operating  independently  or  in  sync  with  the 
others.”  (Fogel,  1992) 


For  the  potential  programmer/ implementor,  Blyth  Software 
Inc.'s  Omnis  7  presents  speed  and  virtually  unlimited 
flexibility  in  the  possible  implementation  of  the  Naval 
Postgraduate  School  Scheduling  System.  Furthermore,  Omnis  7 
can  be  found  in  the  NPS  software  inventory  which  may  preclude 
its  purchase  for  any  follow-on  work  to  NPS3  (Ragan,  1992) . 
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APPENDIX  A:  CURRENT  NPS3  PHYSICAL  DATA  FLOW  DIAGRAMS 

In  the  following  figures,  FIG.  A-l  thru  FIG.  A- 6,  the 
physical  context  data  flow  diagrams  and  the  physical  systems 
level  data  flow  diagrams  for  the  current  NPS  Scheduling  System 
are  presented  so  that  the  reader  may  obtain  a  more  detailed 
understanding  of  what  the  current  system  does  and  how  the 
current  system  is  implemented. 
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FIG.  A-l,  Physical  Context  Dataflow  Diagram 
of  the  current  NPS  Scheduling  System. 


FIG.  A-2,  Physical  Context  Dataflow  Diagram 
of  the  current  NPS  Scheduling  System,  cont'd. 


FIG.  A  -  3 ,  Physical  Context  Dataflow  Diagram 


of  the  current  NPS  Scheduling  System,  cont'd. 


FIG.  A-4,  Physical  Systems  Dataflow  Diagram  of 
inputs  to  the  Course  Scheduling  Process. 
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FIG.  A-5,  Physical  Systems  Dataflow  Diagram  of 
outputs  from  the  Course  Scheduling  Process. 
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FIG.  A-6,  Physical  Systems  Dataflow  Diagram  of 
the  remaining  NPS  Scheduling  System  Processes. 


APPENDIX  B:  NPS3  ENTITY  RELATIONSHIP  DIAGRAMS 

The  following  report  presents  the  Entity  Relationship 
Diagrams,  FIG.  B-l,  for  the  proposed  Naval  Postgraduate  School 
Scheduling  System  (NPS3) .  Following  FIG.  B-l  are  the  Entity 
definitions  followed  with  the  definitions  for  each  of  the 
Entity  Attributes. 
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FIG.  B-l,  NPS  Scheduling  System  Entity 
Relationship  Diagram. 


ENTITY  DEFINITION 


Entity: 

Description: 

Key 

Attributes : 


Other 

Attributes : 


BUILDING 

This  identifies  the  building  of  which 
classrooms,  laboratories  and  final  exam  rooms 
are  located  in  during  an  academic  quarter  at 
NPS . 


BUILDING_CODE ;  Building_letter_code 

BUILDING_NAME ;  Building_name 

Always  CONTAINS  many  ROOMS. 

Always  CONTAINS  many  FINAL_EXAM_ROOMs . 


Relationships : 


Entity*  COURSE 

Description:  This  identifies  the  entire  list  of  courses 

available  at  NPS  based  on  the  E-Z  Demand 
List . 

Key 

Attributes  * 

COURSE_TYPE;  Course_type 
COURSE_NUMBER;  Course_number_code 

Other 

Attributes : 

FINAL_EXAM;  Final_exam_course_indicator 
REFRESHER  COURSE;  Ref resher_course_indicator 
NO_OF_SEGMENTS ;  Total_number_of_course 

_segments 

LECT_HRS ;  Course_lecture_credit_hours 
LAB_HRS ;  Course_lab_credit_hours 
COURSE_REQUIRED_TIME ;  Scheduled_required_ 

timeperiod_for_course_indicator 
INSTRUC_REQUIRED_TIME ;  Scheduled_required 

timeperiod_for_instructor_indicator 
DIVERS ITY_OF_MAJORS ;  Diversi ty_of_ma j  ors 

_indicator 

TECH_LAB;  Technical_lab_indicator 
SIMULTANEOUS_SCHED_COURSE ;  Simul taneously_ 

scheduled_course 

ACCELERATED_COURSE ;  Accelerated_course_ 

indicator 

S PECIAL_ROOM_REQUIREMENT ;  Spec ial_room_ 

requirements 

REQUIRED_LAB  ROOM;  Required_laboratory_room 
DEPT_LTR_CODEFK;  Department_letter_code 
FIN_EX_RM_CARD_NUMBERfk;  Final_exam_room 

schedule_card_number 
SCG_CARD_NUMBERfk  ;  S tudent_course_group_ 

schedule_card_number 

INSTRUC_CARD_NUMBERfk;  Instructor_schedule_ 

card_number 

ROOM_CARD_NUMBERfk  ;  Room_s  chedul e_card_number 
QTR_NUMBERfk;  Schedule_quarter_number 
YEARfk;  Schedule_year 
COMMENTS;  Scheduler_course_comments 
STATUS;  Course  schedule  status 


Relationship 


Sometimes  DIVIDED_INTO  many  COURSE_SEGMENTs 
Always  OFFERED_BY  one  DEPARTMENT. 

Sometimes  DISPLAYED_ON  one  INSTRUCTOR_SCHED 
Sometimes  REQUIRES  one  FINAL_EXAM. 
Sometimes  DISPLAYED_ON  one  ROOM_SCHED. 
Sometimes  DISPLAYED_ON  one 
FINAL_EXAM_ROOM_SCHED . 

Sometimes  DISPLAYED__ON  one 
STUDENT  COURSE  GRP  SCHED. 


TITY  DEFINITION 


Entity: 

Description: 


COURSE_SEGMENT 

This  identifies  all  courses  and  their 
corresponding  course  segments . 


Key 

Attributes : 


Other 

Attributes : 


Relationships : 


COURSE_TYPEFK;  Course_type 
COURSE_NUMBERFK;  Course_number_code 
SEGMENT_NUMBER ;  Course_segment_number 


SEGMENT_STUDENTS ;  Course_segment_number_of_ 

students 

LAB;  Lab_indicator 

TEACHING_TEAM ;  Teaching_team_indicator 
DES IGNATED_STUDENT_COURSE_GRP ;  Des igna t ed_ 

student_course_group_for_ 

course_segment 

BUILDING_CODEFK;  Building_letter_code 
ROOM  NUMBERfk;  Ro om_numb e r _ i n_bu i 1 d i ng 
DAYFr;  Academic_day~ 

PERIODfk;  Academic_hour 

FACULTY_CODEfk;  Department_faculty_code 
DEPT_LTR_CODEf  ,*  Department_letter_code 
STATUS;  Course_schedule_status 

Always  ASSIGNED_TO  one  COURSE. 

Always  ASSIGNED  one  ROOM. 

Always  ASSIGNED  one  TIME_PERIOD. 

Always  TAUGHT_BY  one  INSTRUCTOR. 

Always  ATTEND ED_B Y  many  STUDENTS. 


ENTITY  DEFINITION 


Entity: 

Description: 

Key 

Attributes : 
Other 

Attributes: 

Relationships : 


CURRIC 

Uniquely  identifies  a  specific  area  of  study, 
at  NPS,  within  a  curriculum  program. 

CURRIC_LTR_CODE;  Curriculum  letter_code 


PROGRAM_LTR_CODEFK  ;  Curriculum_program_letter 

_code 

Always  CONSISTS_OF  many  CURRIC_SECTIONs . 
Always  BELONGS_TO  one  CURRIC_PROGRAM. 


Entity: 

Description: 

Key 

Attributes: 

Other 

Attributes : 


ENTITY  DEFINITION 

CURRIC_PROGRAM 

Uniquely  identifies  an  overall  area  study,  at 
NPS ,  that  may  encompass  many  curriculums. 

PROGRAM_LTR_CODE ;  Curriculum_program_letter 

code 


Relationships:  Always  CONSISTS_OF  many  CURRICulums . 


ENTITY  DEFINITION 


Entity: 

Description: 

Key 

Attributes : 

Otner 

Attributes : 
Relationships 


CURRIC_SECTION 

Uniquely  identifies  a  section  of  students 
assigned  to  the  same  curriculum. 


CURRIC_LTR_CODEfk;  Curriculum_letter_code 
SECTION  NUMBER;  Curriculum  section  number 


Always  BELONGS_TO  one  CURRICulum. 

Always  AS S IGNED_TO  many  STUDENT_COURSE_GRPs . 


ENTITY  DEFINITION 


Entity:  DEPARTMENT 

Description:  This  identifies  the  research/teaching 

organizational  unit  at  NPS. 

Key 

Attributes:  DSPT_LTR_CODE ;  Department_letter_code 

Other 

Attributes : 

DEPT_NAME ;  Department__name 
MSTR_INSTR_SCHD_QTR_NAMEFK; 

Mas ter_inst ruction  schedule_quarter_name 
MSTR_INSTR_SCHD_YEARFK; 

Master_instruction_schedule_year 

Relationships:  Always  OFFERS  many  COURSES. 

Always  PROVIDES  many  INSTRUCTORS. 

Always  CONTAINS  many  FACULTY. 

Always  D I S  PLAYED_ON  one  MASTER_INSTRUC_SCHED . 


ENTITY  DEFINITION 


Entity: 

Description: 

Key 

Attributes : 

Other 

Attributes : 


Relationships 


FACULTY 

This  identifies  the  members  of  a  pari'icular 
department . 


DEPT_LTR_CODEfk;  Department_letter_code 
FACULTY_CODE ;  Department_f aculty_code 


FACULTY_NAME ;  Facul ty_name 
ACAD_COUNC I L_MBRS HP ;  Academi c_counc i 1 

_membership_indicator 

FAC_COUN C I L_0 F F__L  1ST;  Facul  ty_council_of  f  icers 

_listing_indicator 

AS W_MBRS H P ;  ASW__academic_group_indicator 
EW_MBRSHP :  EW_academic_group_indicator 
C3_MBRSHP ;  C3_academic_group_indicator 
SSAG_MBRSHP ;  Space_systems_academic 

_group_indicator 

Always  BELONGS_TO  one  DEPARTMENT. 


ENTITY  DEFINITION 


Entity*  FINALJ3XAM 

Description:  This  identifies  a  course  and/or  course 

segment  that  requires  a  final  exam. 


Attributes:  COURSE_TYPEFK;  Course_type 

COURSE_NUMBERFk;  Course__number_code 
SEGMENT_NUMBERf*;  Course_segment_number 

Other 

Attributes : 

BUILDING_CODEfk;  Building_letter__code 
FINAL_EXAM_ROOM_NUMBERfk;  Final_exam_room 

_numb e r _ i n_bu i 1 d i ng 

FINAL_EXAM_DAYfk;  Final_exam_academic_day 
FINAL_EXAM  PERIODFK;  Final_exam_academic_hour 


Relationships:  Always  GIVEN_IN  one  FINAL_EXAM_ROOM. 

Always  GIVEN_FOR  one  COURSE. 

Always  ASSIGNED  one  FINAL_EXAM_TIME_PERIOD . 


Entity:  FINAL_EXAM_ROOM 

Description:  This  identifies  the  building  and  room  in 

which  a  final  exam  for  a  course  and/or  course 
segment  is  given  in. 

Key 

Attributes : 

BUILDING_CODEfk;  Building_let ter__code 
FINAL_EXAM_RGOM_NUMBER ;  Final_exam_room 

_number_in_building 

Other 

Attributes : 

CAPACITY;  Room_seating_capacity 
ARRANGEMENT ;  Room_seat ing_arrangements 
FEATURES ;  Room_f eatures_or_equipment 
TYPE ;  Room_type 

FIN_EX_RM__CARD_NUMBERFK ;  Final_exam_room 

_s  chedul  e_card_number 

Relationships:  Always  SCHEDULED_FOR  many  FINAL_EXAMs . 

Always  BELONGS _T0  one  BUILDING. 

Always  RECEIVES  one  FINAL_EXAM_ROOM_SCHED . 


ENTITY  DEFINITION 


Entity:  FINAL_EXAM_ROOM_SCHED 

Description:  This  identifies  the  final  exam  schedule  for 

a  final  exam  room. 

Key 

Attributes: 

FIN_EX_RM_CARD_NUMBER ;  Pinal_exam_room 

_schedule_card_number 
QTRJNUMBER;  Schedule_quarter_number 
YEAR;  Schedule_year 

Other 

Attributes : 

BUILDING_CODEfk;  Building_letter_code 
FINAL_EXAM_ROOM_NUMBERfk ;  Final_exam_room 

_number_in_building 


Relationships:  Always  DISPLAYS  many  COURSES. 

Always  BELONGS_TO  one  FINAL_EXAM_ROOM . 


ENTITY  DEFINITION 


Entity:  FINAL_EXAM_TIME  PERIOD 

Description:  This  identifies  the  scheduled  day  and  time 

that  a  final  exam  is  given  in  a  final  exam 
room. 

Key 

Attributes:  FINAL_EXAM_DAY;  Final_exam_academic_day 

FINAL_EXAM_PERIOD ;  Final_exam_academic_hour 

Other 

Attributes : 

COURSE_TYPEfk;  Course_type 
COURSE_NUMBERfk;  Course_number_code 
SEGMENT_NUMBER  ,•  Course_segment_number 

Relationships:  Always  ASSIGNED__TO  one  FINAL_EXAM. 


Entity: 

Description 


Key 

Attributes : 


Other 

Attributes : 


Relationships : 


ENTITY  DEFINITION 


INSTRUCTOR 

This  identifies  the  person  who  teaches  a 
particular  course  and/or  course  segment. 


DEPT_LTR_CODEfk;  Department_letter_code 
FACULTY_CODE ;  Department_f acul ty_code 


INSTRUC_NAME ;  Instructor_name 
DEPT_CHAIR_OR_DEAN ;  Department_chairman_or 

dean_indicator 

ACAD_COUNCIL_MBRSHP ;  Academic_council 

_membership_indicator 
FAC_COUNCIL_OPF_LIST;  Faculty_council 

_of f icers_listing_indicator 
ASW_MBRSHP ;  ASW_academic_group_indicator 
EW_MBRSHP :  EW  academicgroup  indicator 
C3_MBRSHP ;  C3_academic_group_indicator 
SSAG_MBRSHP ;  Space_systems_academic 

group_indicator 

INSTRUC_CARD_NUMBERFJC;  Ins  t  rue  t  or_s  chedul  e 

_card_number 

Always  PROVIDED_BY  one  DEPARTMENT. 
Sometimes  TEACHES  many  COURSE_SEGMENTs . 
Sometimes  BELONGS_TO  many 
SEMI_PERM_EVENT_MEMSHPs . 

Always  RECEIVES  one  INSTRUCTOR_SCHED . 


Entity:  INSTRUCT0RJ3CHED 

Description:  This  identifies  the  schedule  for  an 

Instructor  during  a  given  quarter. 

Key 

Attributes : 

INS TRUC_CARD_NUMB  ER ;  Instructor_schedule 

_card_number 

QTR_NUMBER;  Schedule_quarter_number 
YEAR;  Schedule_year 

Other 

Attributes : 

DEPT_LTR_CODEFK;  Department_letter_code 
FACULTY_CODEfk;  Department_faculty_code 
INSTRUC_NAME ;  Inst rue tor_name 


Relationships:  Always  BELONGS_TO  one  INSTRUCTOR. 

Always  DISPLAYS  many  COURSES. 


ENTITY  DEFINITION 


Entity: 

Description: 

Key 

Attributes: 

Other 

Attributes : 


MAS  TER_ INS  TRUC_SCHED 

This  identifies  the  schedule  for  all  courses 
offered  during  a  given  quarter. 


MS TR_INSTR_SCHD_QTR_NAME; Mas ter_inst ruction 
_schedule_quarter_name 
MSTR_INSTR_SCHD_YEAR ;  Master_inst ruction 
_schedule_year 


Relationships :  Always  DISPLAYS  many  DEPARTMENTS. 


Entity*  ROOM 

Description:  This  identifies  a  classroom  or  a  laboratory 

that  a  course  or  course  segment  is  taught  in. 

Key 

Attributes : 

BUILD ING_CODEfk  ;  Bu i 1 d ing_l e 1 1 e r _c ode 
ROOM_NUMBER;  Room_number_in_building 

Other 

Attributes : 

CAPACITY;  Room_seating_capacity 
ARRANGEMENT;  Room_seating_arrangements 
FEATURES ;  Room_f eatures__or_equipment 
TYPE ;  Room_type 

ROOM_CARD_NUMBER ;  Room_schedule 

card  number 


Relationships:  Sometimes  ASS IGNED_TO  many  COURSE_SEGMENTs . 

Sometimes  RECEIVES  one  ROOM_SCHED. 

Always  BELONGS_TO  one  BUILDING. 

Sometimes  ASSIGNED_TO  many  SEMI_PERM_EVENTs  . 


ENTITY  DEFINITION 


Entity:  ROOM_SCHED 

Description:  This  identifies  the  schedule  for  a  given 

classroom  or  laboratory. 

Key 

Attributes : 

ROOM_CARD_NUMBER ;  Room_schedule_card_nuiriber 
QTR_NUMBER;  Schedule_quarter_number 
YEAR;  Schedule_year 

Other 

Attributes : 

BUILD ING_CODEfk;  Building_letter_code 
ROOM_NUMBERfk  ;  Room_niamber_in_building 

Relationships:  Always  BELONGS_TO  one  ROOM. 

Always  DISPLAYS  many  COURSES. 


V 


Entity: 

Description: 

Key 

Attributes : 

Other 

Attributes : 


Relationships : 


ENTITY  DEFINITION 


SEMI_PERM_EVENT 

This  identifies  an  event  that  is  scheduled 
during  the  same  time  period  every  quarter. 


EVENT_TYPE;  Semi_permanent_event_type 
EVENT_NAME;  Semi_permanent_event_name 


BUILDING_CODEfk  ;  Bu i 1 d i ng_l e 1 1  er_c ode 
ROOM  NUMBERfk;  Room_number_in_building 
DAYf^;  Academic_day 
PERIODfk;  Academic  hour 


Always  ASSIGNED  one  ROOM. 

Always  GIVEN_FOR  many 
SEMI_PERM_EVENT_MEMSHPs . 

Always  ASSIGNED  one  TIME_PERIOD. 


Entity: 

Description: 


Key 

Attributes: 


ENTITY  DEFINITION 


SEMI  PERM  EVENT  MEMSHP 


This  identifies  the  membership  for  a  semi 
permanent  event  at  NPS . 


EVENT__TYPEfk;  Semi_permanent_event_type 
EVENT_NAMEFK;  Semi_permanent_event_name 
FACULTY_CODEfk;  Department_f aculty_code 
DEPT_LTR_CODEp'c;  Department_letter_code 
CURR I C_LTR_CODE FK ;  Cu  r  r i cu 1 um_l etter_code 
SECTION_NUMBERfk;  Curriculum_section_number 
GROUP_NUMBERfk;  Curriculum_student 

_course_group_number 


Other 

Attributes : 


Relationships : 


Always  ATTENDS  one  SEMI_PERM_EVENT. 
Sometimes  CONSISTS_OF  one  INSTRUCTOR. 
Sometimes  CONSISTS_OF  one 
STUDENT  COURSE  GRP. 


ENTITY  DEFINITION 


Entity:  STUDENT 

Description:  This  identifies  a  person  attending  a  course 

of  instruction  at  NPS. 

Key 

Attributes : 

STUD_SSN;  Student_social_security_number 

Other 

Attributes : 

STUD_NAME ;  Student_name 

CURRIC_LTR_CODEfk;  Curriculum_letter__code 
SECTION_NUMBERFK;  Curriculum_section_number 
GROUP_NUMBERfk;  Curriculum_student 

c  ou  r  s  e_g  roup_number 
SCG_CARD_NTJMBERFK;  Student_course 

_group_schedule_card_number 
QTR  NUMBERfk;  Schedule_quarter_number 
YEAr7k;  Schedule_year 
COURSE_TYPEfk  ;  Course_type 
COURSE_NUMBERfk;  Course_number_code 
S EGMENT__NUMBERF* ;  Course_segment_number 


Relationships:  Always  BELONGS_TO  one  STUDENT_COURSE_GRP . 

Always  RECEIVES  one  STUDENT_COURSE_GRP_SCHED . 
Sometimes  ENROLLED  IN  one  COURSE  SEGMENT. 


ENTITY  DEFINITION 


Entity: 

Description: 

Key 

Attributes : 

Other 

Attributes : 


Relationships : 


STUDENT_COURSE_GRP 

This  identifies  the  group  of  students  taking 
the  same  courses  during  a  quarter  at  NPS. 


CURRIC_LTR_CODEFK;  Curriculum_letter_code 
SECTION_NUMBERfk;  Curriculum_section_number 
GROUP_NUMBER ;  Curriculum_student 

_course_group_number 


GROUP_STUDENTS ;  Curriculum_student 

_c  our s  e_g  r oup_number_o  f _s  t uden t  s 
UNUSUAL_COURSE_COMBINATION;  Unusual_COurse 
combination  indicator 


Always  ASSIGNED  one  CURRIC_SECTION. 

Always  CONSISTS_OF  many  STUDENTS  (may  consist 
of  one  student) . 

Sometimes  BELONGS_TO  many 
SEMI_PERM_EVENT_MEMSHPs . 

Always  RECEIVES  one  STUDENT_COURSE_GRP_SCHED . 


ENTITY  DEFINITION 


Entity: 

Description: 

Key 

Attributes: 

Other 

Attributes : 


Relationships : 


STODENT_COURSE_GRP_S CHED 

This  identifies  the  schedule  for  students 
taking  the  same  courses  during  a  quarter  at 
NPS . 


SCG_CARD_NUMBER ;  Student_course_group 

_s  chedul e_card_number 
QTR_NUMBER;  S chedul e_quarter_number 
YEAR;  S chedul e_year 


CURRIC_LTR_CODEfk;  Curriculum_letter_code 
SECTION_NUMBERfk;  Curriculum_section_number 
GROUP_NUMBERfk;  Curriculum_student 

_course_group_number 


Always  BELONGS_TO  many  STUDENTS  (may  belong 
to  one  student) . 

Sometimes  DISPLAYS  many  COURSES. 

Always  BELONGS_TO  one  STUDENT_COURSE_GRP . 


ENTITY  DEFINITION 


Entity: 

Description: 

Key 

Attributes : 


Other 

Attributes : 


Relationships : 


TIME_PERIOD 

This  identifies  the  day  and  time  that  a 
course,  course  segment  or  semi  permanent 
event  is  scheduled. 


DAY;  Academic_day 
PERIOD;  Academic_hour 


Sometimes  ASSIGNED_TO  many  SEMI_PERM_EVENTs 
Sometimes  ASSIGNED_TO  many  COURSE_SEGMENTs 


ATTRIBUTE  DEFINITIONS 


Academic_council_membership_indicator : 

Text  1,  Mask  X 

where  X  is  Y  or  N 

Indicates  membership  in  Academic  Council 

Academic_day : 

Text  9 

Name  of  the  day  of  the  academic  week 

Academic_hour : 

Numeric  1 

Hour-long  period  during  the  academic  day 

Accelerated_course_indicator : 

Text  1,  Mask  X, 

where  X  is  Y  or  N 

Indicates  courses  normally  scheduled  for  double  the 
course  load 

ASW_academic_group_indicator : 

Text  1,  Mask  X 

where  X  is  Y  or  N 

Indicates  membership  in  ASW  academic  group 

Building_letter_code : 

Text  1 

First  letter  of  the  name  of  a  particular  academic 
building 

Building_name : 

Text  20 

Name  of  an  academic  building 

C3_academic_group_indicator : 

Text  1,  Mask  X 

where  X  is  Y  or  N 

Indicates  membership  in  C3  academic  group 

Course_lab_credit_hours : 

Numeric  1 

Number  of  credit  hours  assigned  to  the  lab  component 
of  a  course  or  its  course  segment 

Course_lecture_credit_hours : 

Numeric  1 

Number  of  credit  hours  assigned  to  the  lecture  component 
of  a  course  or  its  course  segment 


Course_number_code : 

Numeric  4,  Mask  NXXX 

where  N  is  0-4,  XXX  is  course  code 
Number  code  assigned  to  a  course 

Course_schedule_status_code : 

Text  4 

Status  of  the  scheduling  of  a  course 

Course_segment_number : 

Numeric  2 

Number  of  the  segment  into  which  a  course  has  been 
divided 

Course_segment_number_of_students : 

Numeric  3 

Number  of  students  assigned  to  a  course  segment 

Course_type : 

Text  2 

Code  for  the  type  subject  a  course  teaches 

Curriculum_letter_code : 

Text  2 

Letter  code  for  a  curriculum  within  a  curriculum  program 

Curriculum_j?rogram_letter_code : 

Text  2 

Letter  code  for  a  curriculum  program 

Curriculum_sect ion_number : 

Numeric  2 

Number  code  for  a  section  within  a  curriculum 

Curriculum_student_course_group_number : 

Numeric  2 

Number  of  a  student  course  group  within  a  curriculum 
section 

Curriculum_student_course_group_number_of_students : 

Numeric  2 

Number  of  students  in  a  student  course  group 

Department_chairman_or_dean_indicator : 

Text  l,  Mask  X 

where  X  is  Y  of  N 

Indicates  Instructor  who  ius  Department  chairman  of  Dean 

Department_f aculty_code : 

Text  2 

Code  used  to  identify  each  faculty  member 


Department_letter_code : 

Text  2 

Alpha  code  used  to  identify  each  department 

Department_name : 

Text  25 

Name  of  department 

Designated_student_course_group_f or_course_segment : 

Text  6,  Mask  XX  YY  ZZ 

where  XX  is  curriculum  letter  code,  YY  is 
curriculum  section  number  and  ZZ  is  curriculum 
student  course  group  number 
Designates  students  to  be  placed  in  specific 
course  segments 

Diversity_of_ma j  ors_indicator : 

Text  1,  Mask  X 

where  X  is  Y  or  N 

Indicates  that  the  course  has  a  diversity  of  majors  in 
its  enrollment 

EW_academic_group_indicator : 

Text  1,  Mask  X 

where  X  is  Y  or  N 

Indicates  membership  in  EW  academic  group 

Faculty_council_of f icers_  listing_indicator : 

Text  1,  Mask  X 

where  X  is  Y  or  N 

Indicates  membership  in  Provost  and  Superintendent 
council 

Faculty_name : 

Text  15 

First  13  letters  of  faculty  member  last  name,  1st 
letter  of  faculty  member  first  name  and  1st  letter 
of  faculty  member  middle  name 
Name  of  faculty  member 

Final_exam_academic_day : 

Text  9 

Name  of  the  day  of  final's  week 

Final_exam_academic_hour : 

Text  l 

Hour-long  period  during  final's  week 

Final_exam_course_indicator : 

Text  1,  Mask  X 

where  X  is  Y  or  N 

Indicates  final  exam  requirement  for  course 


Final_exam_room_number_in_building : 

Text  4,  Mask  NNNA 

where  NNA  is  the  sequential  number  of  a  room  and 
A  is  a  letter  designator  for  a  subdivision  of 
a  room 

Number  assigned  to  a  room  in  a  building  used  for  a  final 
exam 

Final_exam__room_schedule_card_number : 

Numeric  4 

Sequential  number  of  a  final  exam  schedule  card  in  a  set 
of  final  exam  schedule  cards 

Instructor_name : 

Text  15 

First  13  letters  of  instructor  last  name,  1st  letter 
of  instructor  first  name  and  1st  letter  of 
instructor  middle  name 
Name  of  an  instuctor 

Instructor_schedule_card_number : 

Numeric  4 

Sequential  number  of  an  instructor  schedule  card  in  a 
set  of  instructor  schedule  cards 

Lab_indicator: 

Text  1,  Mask  X 

where  X  is  Y  or  N 

Indicates  that  the  particular  course  segment  is  a 
laboratory 

Master_instruction_schedule_year : 

Numeric  4 

Year  for  which  the  Master  Instruction  schedule  is 
written 

Master_instruction_schedule_quarter_name : 

Text  6 

Name  of  the  season  at  the  beginning  of  the  quarter  of 
the  academic  year 

Ref resher_course_indicator : 

Text  1,  Mask  X 

where  X  is  Y  or  N 

Indicates  a  course  is  a  refresher  course 

Required_laboratory_room: 

Text  6,  Mask  X-NNNA 

where  X  is  first  letter  of  building,  NNN  is 
sequential  number  of  a  room  and  A  is  letter 
designator  for  a  room  subdivision 
Number  assigned  to  a  required  laboratory  room  for  a 
course  lab 


Room_features_or_equipment 
Text  20 

Description  of  features  of  qpuipment  about  a  room  that 
distinguish  it  from  ther  rooms 

Room_number_in_building : 

Text  4 ,  Mask  NNNA 

where  NNN  is  sequential  number  of  a  room,  A  is 
letter  designator  for  a  room  subdivision 

Room_schedule_card_number : 

Numeric  4 

Sequential  number  of  a  room  schedule  card  in  a  set  of 
room  schedule  cards 

Room_seating_arrangements : 

Text  l.  Mask  X 

where  X  is  values  T (tables  and  chairs)  or 
D (desks)  seating  arrangements  for  students 
taught  in  a  room 

Room_seating_capacity : 

Numeric  3 

Number  of  chairs  with  table  space  or  desks  or  standing 
room;  functional  student  capacity 

Room_type : 

Text  2,  Mask  XX 

where  XX  is  values  CR  (classroom)  or  LB 
(laboratory)  or  SC  (secure  class)  or  SL 
(secure  lab) 

Specifies  the  type  of  room 

Schedule_quarter_number : 

Numeric  1 

Sequential  number  of  a  quarter  in  a  schedule  year 

Schedule_year : 

Numeric  4 

Year  for  which  a  schedule  is  written 

Scheduled_required_timeperiod__for_instructor_indicator : 

Text  1,  Mask  X 

where  X  is  Y  or  N 

Indicates  that  course  has  a  required  timeperiod  for  the 
instructor 

Scheduled_required_timeperiod_f or_course_indicator : 

Text  1,  Mask  X 

where  X  is  Y  or  N 

Indicates  that  course  has  a  required  timeperiod 


Scheduler_course_comments : 

Text  50 

Comments  from  course  schedulers  regarding  course 

Semi_permanent_event_name : 

Text  10 

First  10  letters  of  a  semi  permanent  event  name  (e.g. 
Dept  mtg) 

Semi_permanent_event_type : 

Text  2 

Code  for  the  type  semi  permanent  event  schedule 

Simultaneously_scheduled_course: 

Text  7,  Mask  XX-NYYY 

where  XX  is  course  type,  N  is  0-4  and  YYY  is 
course  code 

Identifies  a  course  that  simultaneously  scheduled  with 
the  course  in  question 

Spac  e_s y s  t  ems_a cademi c_i nd i c a t o r : 

Text  1,  Mask  X 

where  X  is  Y  or  N 

Indicates  membership  in  Space  systems  academic  gruop 

Special  room_requirements : 

Text  20 

Special  room  features  that  a  given  course  requires  (eg 
computor  terminals,  classified  rooms,  NSA  map  rooms) 

Student  _course_group_schedule_card_number : 

Numeric  4 

Sequential  number  of  a  student  course  group  schedule 
card  in  a  set  of  student  course  group  schedule  cards 

Student  _name : 

T<-  xt  15 

F:' rst  13  letters  of  student  last  name,  first  letter  of 
student  first  name,  first  letter  of  student  middle 
name 

Student  _social_security_number : 

Numeric  9 

Social  security  number  of  a  person 

Teaching_team_indicator : 

Text  1,  Mask  X 

where  X  is  Y  or  N 

Indicates  a  course  is  taught  by  a  team  of  instructors 


Technical_lab_indicator : 

Text  1,  Mask  X 

where  X  is  Y  or  N 

Indicates  that  a  course  labortary  is  technical  in  nature 

Total_number_of_course_segments : 

Numeric  1 

Total  number  of  course  segments  a  course  is  divided  into 

Unusual_course_combination_indicator: 

Text  1,  Mask  X 

where  X  is  Y  or  N 

Indicates  unusual  course  combinations  for  a  student 
course  group 


APPENDIX  C:  NPS3  LOGICAL  DATA  FLOW  DIAGRAMS 

In  an  attempt  to  gain  a  more  detailed  description  of  the 
NPS  Scheduling  System  user  requirements  presented  by  Nolan  and 
Youngblood,  and  to  enhance  possible  alternative  implementation 
solutions,  the  logical  dataflow  diagrams  for  NPS3  are 
presented  in  FIG.  C-l  thru  FIG.  C-38.  The  Demarco- Yourdon 
system  for  dataflow  diagrams  is  used. 
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FIG.  C-1;  Logical  Context  Dataflow 
Diagram  of  the  target  NFS  Scheduling 
System . 


FIG.  C-2 ,  Logical  Systems  Dataflow 
Diagram  of  the  target  NFS  Scheduling 
System . 


FIG.  C-3,  Logical  Systems  Dataflow 
Diagram  of  the  target  NFS  Scheduling 
System,  cont'd. 


FIG.  C-5,  Logical  Dataflow  Diagram  for 
Euent/Course  Scheduling. 
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FIG.  C-6,  Logical  Dataflow  Diagram  for 
Scheduling  Data  Maintenance. 


FIG.  C-?i  Logical  Dataflow  Diagram  for 
the  target  Schedules  and  Deporting  support 


FIG.  C-8,  Logical  Dataflow  Diagram  for 
INSTRUCTOR  SCHED  Data  Store  Maintenance 


FIG.  C  -  9 ,  Logical  Dataflow  Diagram  for 
INSTRUCTOR  Data  Store  Maintenance. 


FIG.  C-10,  Logical  Dataflow  Diagram  for 
COURSE  Data  Store  Haintenance. 


FIG.  C-ll,  Logical  Dataflow  Diagram  for 
COURSE  SEGMENT  Data  Store  Maintenance. 


FIG.  C-12,  Logical  Dataflow  Diagram  fo 
BOOn  SCHED  Data  Store  ha i ntenance . 


FIG.  C-13,  Logical  Dataflow  Diagran  for 
TIME  PERIOD  Data  Store  Maintenance. 


FIG.  C-14,  Logical  Dataflow  Diagram  for 
STUDENT  COURSE  GRP  SCHED  Data  Store 
11a  i  nt enance  . 


FIG.  C-17,  Logical  Dataflow  Diagram  for  the 
target  Final  Exam  Scheduling. 


FIG.  C-18,  Logical  Dataflow  Diagram  for  the 
target  Final  Exam  Data  Maintenance. 


FIG.  C-19,  Logical  Dataflow  Diagram  for 
FINAL  EXAM  Data  Store  Maintenance. 


FIG.  C-20,  Logical  Dataflow  Diagram  for 
FINAL  EXAM  ROOM  Data  Store  Maintenance. 


FIG.  C-21,  Logical  Dataflow  Diagram  for 
FINAL  EXAM  TIME  PERIOD  Data  Store 
Maintenance. 


FIG.  C-22,  Logical  Dataflow  Diagram  for 
FINAL  EXAM  SCHED  Data  Store  Maintenance 


FIG.  C-23,  Logical  Dataflow  Diagram  for 
the  target  Master  Instruction  Schedule 
Subsystem . 


FIG.  C-25,  Logical  Dataflow  Diagram  for 
Scheduling  Data  Graph  Data  Maintenance. 


FIG.  C-26,  Logical  Dataflow  Diagram  for 
ROOM  Data  Store  Maintenance. 


FIG.  C-27 ,  Logical  Dataflow  Diagran  for 
STUDENT  Data  Store  Maintenance. 


FIG.  C-28,  Logical  Dataflow  Diagram  for 
the  target  Supplementary  Database  Subsystem. 


FIG.  C-23,  Logical  Dataflow  Diagram  for 
Supplementary  Database  Data  Maintenance 


FIG.  C-30;  Logical  Dataflow  Diagram  for  the 
target  Supplemetary  Database  Reports  and 
Lists  support. 


FIG.  C-31,  Logical  Dataflow  Diagram  for 
CURRIC  PROGRAM  Data  Store  Maintenance. 


FIG.  C-32*  Logical  Dataflow  Diagram  for 
CURRIC  Data  Store  Maintenance. 


FIG.  C-34,  Logical  Dataflow  Diagram  for 
CURRIC  SECTION  Data  Store  Maintenance. 


FIG.  C-35#  Logical  Dataflow  Diagram  for 
FACULTY  Data  Store  Maintenance. 


FIG.  C-36,  Logical  Dataflow  Diagram  for 
SEMI  PEBM  EUENT  Data  Store  Kaintenance. 


FIG.  C-37,  Logical  Dataflow  Diagram  for 
SEMI  PERM  EUENT  MEMSHP  Data  Store 
Ma intenance . 


FIG.  C-38,  Logical  Dataflow  Diagram  for 
BUILDING  Data  Store  Maintenance. 


APPENDIX  D:  NPS3  STRUCTURE  CHARTS 

The  following  report  graphically  depicts  a  computer  system 
structured  design,  in  the  form  of  structure  charts,  FIG.  D-l 
thru  FIG  D- 44 ,  for  implementing  the  requirements  for  the 
scheduling  of  courses  at  the  Naval  Postgraduate  School. 

The  design  of  the  Final  Exam  Scheduling,  Master 
Instruction  Schedule  and  Scheduling  Data  Graph  applications 
are  beyond  the  scope  of  this  thesis  and  are  therefore  not 
addressed,  except  to  show  there  organization  in  FIG.  D-l  as 
#'s  5,  6  and  7,  respectively.  Although  not  addressed  here, 
the  advantages  of  structured  Design  allow  for  these 
applications  to  be  easily  added  to  NPS3  in  the  future. 
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Fig.  D-4,  DETERMINE  HELP  INSTRUCTIONS 
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Fig.  D-17,  DETERMINE  HELP  INSTRUCTIONS 
for  Euent^Course  Transaction  Screen. 
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Fig.  D-21,  DETERMINE  HELP  INSTRUCTIONS 
for  Course/Lab  Scheduling  Screen. 
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Fig.  D-23,  UAL IDATE  AND  ECHO  SCHEDULE 
CONFLICT'ALTERNATIUE  SCREEN. 


Fig.  D-26 «  SCHEDULE  COURSES  VK 
REQUIRED  TIME  PERIOD  FOR  INSTRUC. 


Fig.  0-27,  SCHEDULE  COURSES  W'  LARGE  9  OF  STUDENTS. 


Fig.  D-28,  SCHEDULE  MIDDLE  PRIOBITV  COURSES. 


4.2.2. 1 


SCHEBULE 
S  I  RULTANE- 


OUS  SCHE- 


S  INULTAHEOUS 
SCHEBULEB 


SIMULTANEOUS 
SCHEBULE* 
COURSE  jr  / 

*  / 


COURSE 


COURSE 

INFO 


0  ROOM 


COURSE 

SEGMENT 


UPBATEB 


SEGMENTS 


UPBATEB 


i  RECORBS 


COURSE  SEGMENT  SCREEN  INFO 
SCREEN  INBICMTOR 
COURSE  TTPE 
COURSE  NUMBER 


-29,  SCHEDULE  SIMULTANEOUS  SCHEDULED  COURSES 


1  COURSE  SEGMENT  SCREEN  INTO 

2  SCREEN  INRICNTOR 
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Fig.  D-31,  SCHEDULE  COURSES  W'  DESIGNATED 
STUDENT  COURSE  GRP. 
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Fig.  D-32,  SCHEDULE  COURSES  REQUIRING  SPECIAL  ROOMS. 
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9.  D-33,  SCHEDULE  LOWER  PRIORI  TV  COURSES. 
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Fig.  D-34,  SCHEDULE  COURSES  W'  REQUIRED 
LAB  ROOM^TIME  PERIOD. 
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Fig.  D-35,  SCHEDULE  COURSES  W' 
DIUERSITY  OF  MAJORS. 
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Fig.  D-37,  SCHEDULE  REMAINING  COURSES 


Fig. 


“38 ,  SAUE  TO  MASTER  SCHEDULE  FILE. 
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MODULE * 


ADD  DATA  RECORD 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


To  add  a  data  record  to  the  given  file. 
VALID  FILE 

N/A 

DETAILS:  (Pre- defined) 

1.  Add  a  record  to  the  VALID  FILE. 

UPDATE  DATABASE  FILES 


MODULE i 


ASSIGN  SEMI -PERM  EVENT  TO  SCHEDULES 


PURPOSE: 

USES: 

RETURNS: 

FUNCTIONAL 


To  assign  the  SEMI -PERM  EVENT  and  its  TIME  PERIOD 
and  ROOM  to  the  related  SCHED  RECORDS. 

SCHED  RECORDS 

SEMI -PERM  EVENT  RECORDS 


N/A 


DETAILS : 

Begin 

SCHED  RECORDS. TIME  PERIOD  :=  SEMI -PERM  EVENT 

RECORD. TIME  PERIOD 
PUT  SEMI -PERM  EVENT  RECORD  in  the  SCHED  RECORDS. 

TIME  PERIOD  Slot 

Call  WRITE  SCG  SCHED  FILE  (UPDATED  SCG  SCHED 

RECORD) 

Call  WRITE  ROOM  SCHED  FILE  (UPDATED  ROOM  SCHED 

RECORD) 

Call  WRITE  INSTRUC  SCHED  FILE  (UPDATED  INSTRUC 

SCHEDRECORD) 

End 


CALLED  BY 


SCHEDULE  SEMI -PERM  EVENTS 


MODULE: 


COPY  MAINFRAME  FILES 


PURPOSE:  To  coordinate  copying  files  downloaded  form  the  NPS 

mainframe  computer. 


USES:  N/A 


RETURNS :  N/A 


FUNCTIONAL  DETAILS: 

Begin 

Call  UPDATE  STUDENT  COURSE  GRP  FILE 
Call  UPDATE  STUDENT  FILE 
Call  UPDATE  COURSE /COURSE  SEGMENT  FILES 
Call  UPDATE  FACULTY  FILE 
End 


CALLED  BY:  SCHEDULING  DATA  MAINTENANCE 


MODULE: 


CREATE  NEW  SCHEDULES 


PURPOSE:  To  coordinate  creation  of  new  event/course 

schedules  based  on  priorities. 


USES :  N/A 


RETURNS :  N/A 


FUNCTIONAL  DETAILS: 

Begin 

Call  SCHEDULE  SEMI -PERM  EVENTS 
Call  SCHEDULE  TOP  PRIORITY  COURSES 
Call  SCHEDULE  MIDDLE  PRIORITY  COURSES 
Call  SCHEDULE  LOWER  PRIORITY  COURSES 
Call  SAVE  TO  MASTER  SCHEDULE  FILE 
End 


CALLED  BY:  MANAGE  EVENT/COURSE  SCHEDULING 


MODULE: 


DELETE 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  delete  a  given  schedule  file. 

VALID  FILE 

N/A 

DETAILS:  ( Pre - defined) 

1.  Delete  the  VALID  FILE. 


CALLED  BY:  DELETE  SCHEDULE  FILE 


MODULE 


DELETE  DATA  RECORD 


PURPOSE:  To  delete  a  data  record  in  the  given  file. 

USES:  VALID  FILE 

RETURNS :  N/A 

FUNCTIONAL  DETAILS:  (Pre- defined) 

1.  Delete  a  record  in  the  VALID  FILE. 

CALLED  BY:  UPDATE  DATABASE  FILES 


MODULE 


DELETE  SCHEDULE  FILE 


PURPOSE:  To  coordinate  deletion  of  a  schedule  file. 

USES :  N/A 

RETURNS :  N/A 

FUNCTIONAL  DETAILS: 

Begin 

Call  GET  VALID  FILE 
Call  DELETE  (VALID  FILE) 

End 

CALLED  BY:  MANAGE  EVENT/COURSE  SCHEDULING 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


CALLED  BY: 


DETERMINE  CONFLICTS 


To  put  the  schedule  information  to  the  related 
SCHEDULE  RECORDS. 


SCHED  RECORDS 
SCHED  INFO 


UPDATED  SCHED  RECORDS 
SCHEDULE  CONFLICT 


DETAILS : 

Begin 

If  INSTRUC  SCHED  RECORD. TIME  PERIOD  AND  ROOM 

SCHED. TIME  PERIOD  AND  STUDENT  COURSE 
GRP. TIME  PERIOD  =  null 

For  INSTRUC  SCHED  RECORD 

Put  {COURSE  TYPE,  COURSE  NUMBER, SEGMENT 

NUMBER,  SEGMENT  STUDENTS,  VALID  ROOM) 
in  TIME  PERIOD  slot 
For  ROOM  SCHED  RECORD 

Put  (COURSE  TYPE,  COURSE  NUMBER,  SEGMENT 
NUMBER,  SEGMENT  STUDENTS,  INSTRUC  CODE) 
in  TIME  PERIOD  slot 
For  STUDENT  COURSE  GRP  RECORD 

Put  (COURSE  TYPE,  COURSE  NUMBER,  SEGMENT 
NUMBER  VALID  ROOM,  INSTRUC  CODE) 
in  TIME  PERIOD  slot 
Return  (UPDATED  SCHED  RECORDS) 

Else  Return  (SCHED  CONFLICT) 

End  if 
End 


DETERMINE  RELATED  SCHEDULE  RECORD  CONFLICTS 
UPDATE  SCHEDULE  RECORDS 


MODULE: 


DETERMINE  HELP  INSTRUCTIONS 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  determine  the  help  instuctions  needed  for  a 
given  screen. 


PASSWORD  SCREEN 
TRANSACTION  SCREEN 
FILE  SCREEN 
PRINT  SCREEN 

COURSE/LAB  SCHEDULING  SCREEN 
SCHEDULE  CONFLICT/ALTERNATIVES  SCREEN 
SCHEDULE  RECORD  SCREEN 

N/A 


DETAILS: 

Begin 

Case  Screen 

When  Screen  =  COURSE/LAB  SCHEDULING  SCREEN 
Call  READ  HELP  INSTRUCTIONS  FILE  (COURSE/LAB 

HELP  SCREEN  INDICATOR) 
When  Screen  =  SCHEDULE  CONFLICT/ALTERNATIVES 

SCREEN 

Call  READ  HELP  INSTRUCTIONS  FILE 

( CONFLICT/ ALTERNATIVESHELP 
SCREEN  INDICATOR) 
When  Screen  =  PASSWORD  SCREEN 

Call  READ  HELP  INSTRUCTIONS  FILE  (PASSWORD 

HELP  SCREEN  INDICATOR) 
When  Screen  =  TRANSACTION  SCREEN 

Call  READ  HELP  INSTRUCTIONS  FILE  (TRANSACTION 

HELP  SCREEN  INDICATOR) 
When  Screen  =  FILE  SCREEN 

Call  READ  HELP  INSTRUCTIONS  FILE  (FILE  HELP 

SCREEN  INDICATOR) 

When  Screen  =  PRINT  SCREEN 

Call  READ  HELP  INSTRUCTIONS  FILE  (PRINT  HELP 

SCREEN  INDICATOR) 

When  Screen  =  SCHEDULE  RECORD  SCREEN 

Call  READ  HELP  INSTRUCTIONS  FILE  (SCHEDULE 

RECORD  HELP  SCREEN  INDICATOR) 

Endcase 

Call  DISPLAY  HELP  SCREEN  (HELP  INSTRUCTONS) 

Call  READ  SCREEN 
If  FLAG  TYPE  =  RETURN 
Go  back  to  where  called 
Elseif  FLAG  TYPE  =  QUIT 
Exit  system 
Endif 
End 


CALLED  BY:  VALIDATE  AND  ECHO  PASSWORD  SCREEN 

VALIDATE  AND  ECHO  TRANSACTION  SCREEN 
VALIDATE  AND  ECHO  FILE  SCREEN 
VALIDATE  AND  ECHO  PRINT  SCREEN 

VALIDATE  AND  ECHO  COURSE/LAB  SCHEDULING  SCREEN 
VALIDATE  AND  ECHO  SCHEDULE  CONFLICT/ALTERNATIVES 

SCREEN 


VALIDATE  AND  ECHO  SCHEDULE  RECORD  SCREEN 


MODULE: 


DETERMINE  MBRSHP  SCHEDS  AND  ROOM  SCHED 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  determine  the  membership  and  room  schedule 
records  for  a  given  semi -permanent  event. 


MBRSHP 

ROOM 

SCHED  RECORDS 


DETAILS : 

Begin 

Call  READ  SCG  SCHED  FILE  (DESIGNATED  STUDENT 

COURSE  GRP)  until  EOF 

Call  READ  ROOM  SCHED  FILE  (ROOM)  until  EOF 
Call  READ  INSTRUC  SCHED  FILE  (INSTRUC  CODE)  until 

EOF 


Return  all  related  SCHED  RECORDS 
End 


CALLED  BY:  SCHEDULE  SEMI -PERM  EVENTS 


MODULE: 

PURPOSE: 

USES: 

RETURNS: 

FUNCTIONAL 


DETERMINE  RELATED  SCHEDULE  RECORD  CONFLICTS 


To  determine  the  SCHEDULE  CONFLICTS  that  exist 
between  the  related  SCHEDULE  RECORDS. 


COURSE  SEGMENT  SCHED  INFO 


NO  CONFLICT  (flag) 
UPDATED  SCHED  RECORDS 
SCHEDULE  CONFLICT 


DETAILS : 

Begin 

Call  READ  ROOM  SCHED  FILE  (ROOM) 

Call  READ  INSTRUC  SCHED  FILE  (INSTRUC  CODE) 

Call  READ  SCG  SCHED  FILE  (DESIGNATED  STUDENT 

COURSE  GRP'S) 

Call  DETERMINE  COMFLICTS  (SCHED  RECORDS,  SCHED 

INFO) 

If  SCHEDULE  CONFLICT  exists 

Return  (SCHED  RECORDS,  SCHEDULE  CONFLICTS) 
Else 

Return  (NO  CONFLICT,  UPDATED  SCHED  RECORDS) 
End  if 
End 


CALLED  BY:  RESOLVE  SCHEDULE  RECORD  CONFLICTS 


MODULE: 


DETERMINE  SEMI -PERM  EVENT  AND  EVENT  MBRSHP 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  determine  a  semi -permanent  event  and  the 
membership  of  that  event. 


N/A 

MBRSHP 

SEMI -PERM  EVENT  RECORD 


DETAILS : 

Begin 

Call  READ  SEMI -PERM  EVENT  FILE 

If  EOF  go  back  to  CREATE  NEW  SCHEDULE  FILE 

Else  CALL  READ  SEMI -PERM  EVENT  MBRSHP  FILE  (EVENT 

TYPE,  EVENT  NAME) 

End  if 

Return  (MBRSHP,  SEMI -PERM  EVENT  RECORD) 

End 


CALLED  BY 


SCHEDULE  SEMI -PERM  EVENTS 


MODULE: 


DISPLAY  COURSE/LAB  SCHEDULING  SCREEN 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  display  a  CRT  screen  for  TIME  PERIOD  and  ROOM 
entry. 


COURSE  SEGMENT  SCREEN  INFO 
SCREEN  INDICATOR 

N/A 


DETAILS : 

Begin 

Call  FORMAT  TO  COURSE/LAB  SCHEDULING  SCREEN 
Put  COURSE  SEGMENT  SCREEN  INFO  and  SCREEN 
INDICATOR  to  COURSE/LAB  SCHEDULING  SCREEN 
Call  PUT  COURSE/LAB  SCHEDULING  SCREEN 
End 


CALLED  BY:  GET  VALID  TIME  PERIOD  AND  ROOM 


MODULE: 


DISPLAY  FILE  SCREEN 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


To  display  a  CRT  screen  for  filename  entry. 

N/A 

N/A 


DETAILS : 

Begin 

Call  FORMAT  TO  FILE  SCREEN 
Call  PUT  FILE  SCREEN  (FILE  SCREEN) 
End 


GET  VALID  FILE 
GET  VALID  FILE  NAME 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


DISPLAY  HELP  SCREEN 

To  display  CRT  screen  of  HELP  INSTRUCTIONS. 

HELP  INSTRUCTIONS 

N/A 


DETAILS : 

Begin 

Call  FORMAT  HELP  SCREEN  (HELP  INSTRUCTIONS) 
Call  PUT  HELP  SCREEN  (HELP  SCREEN) 

End 


CALLED  BY 


DETERMINE  HELP  INSTRUCTIONS 


MODULE  s 


DISPLAY  PASSWORD  SCREEN 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


To  display  a  CRT  screen  for  password  entry. 

N/A 

N/A 


DETAILS : 

Begin 

Call  FORMAT  TO  PASSWORD  SCREEN 
Call  PUT  PASSWORD  SCREEN  (PASSWORD  SCREEN) 
End 


GET  VALID  PASSWORD 


MODULE 


DISPLAY  PRINT  SCREEN 


PURPOSE  s 

USES: 

RETURNS: 

FUNCTIONAL 


To  display  a  CRT  screen  for  selecting  an  item  to 
print . 


N/A 

N/A 


DETAILS : 

Begin 

Call  FORMAT  TO  PRINT  SCREEN 
Call  PUT  PRINT  SCREEN  (PRINT  SCREEN) 
End 


CALLED  BY 


GET  VALID  ITEM  TO  PRINT 


MODULE  j 


DISPLAY  SCHEDULE  CONFLICT/ALTERNATIVES  SCREEN 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  display  a  CRT  screen  for  selection  of  an 
alternative  TIME  PERIOD. 


ALTERNATIVES 
SCHEDULE  CONFLICT 


N/A 


DETAILS : 

Begin 

Call  FORMAT  TO  SCHEDULE  CONFLICT/ALTERRNATIVES 

SCREEN 

Put  ALTERNATIVES  and  SCHEDULE  COMFLICT  to 

SCHEDULE  CONFLICT/ALTERNATIVES  SCREEN 
Call  PUT  SCHEDULE  CONFLICT/ ALTERNATIVES  SCREEN 
End 


CALLED  BY:  RESOLVE  SCHEDULE  RECORD  CONFLICT 
RESOLVE  UPDATE  CONFLICTS 


MODULE:  DISPLAY  SCHEDULE  RECORD  SCREEN 

PURPOSE:  To  display  a  CRT  screen  for  input  by  the  system 

user  of  schedule  of  schedule  records  to  get  to 
update . 

USES :  N/A 

RETURNS :N/A 

FUNCTIONAL  DETAILS: 

Begin 

Call  FORMAT  TO  SCHEDULE  RRECORD  SCREEN 
Call  PUT  SCHEDULE  RECORD  SCREEN 
End 


CALLED  BY:  GET  VALID  SCHEDULE  RECORDS  TO  UPDATE 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


DISPLAY  TRANSACTION  SCREEN 


To  display  a  CRT  screen  for  TRANSACTION  entry. 


NPS3  TRANSACTIONS 
DATA  MAINTENANCE  TRANSACTIONS 
UPDATE  TRANSACTIONS 
EVENT/COURSE  TRANSACTIONS 


N/A 


DETAILS : 


Begin 

Call  FORMAT  TO  TRANSACTION  SCREEN 

Call  PUT  TRANSACTION  SCREEN  (TRANSACTION  SCREEN) 

End 


GET 

GET 

GET 

GET 


VALID  NPS  SCHEDULING  SYSTEM  TRANSACTION 
VALID  DATA  MAINTENANCE  TRANSACTION 
VALID  EVENT/COURSE  SCHEDULING  TRANSACTION 
VALID  FILE  UPDATE  TRANSACTION 


MODULE  s 


FORMAT  TO  COURSE /LAB  SCHEDULING  SCREEN 


PURPOSE: 

USES: 

RETURNS: 

FUNCTIONAL 


To  format  the  screen  for  TIME  PERIOD  and  ROOM 
entry. 

N/A 

COURSE/LAB  SCHEDULING  SCREEN 

DETAILS : 

1.  Format  screen  for  COURSE/LAB  TIME  PERIOD  and 
ROOM  entry. 


CALLED  BY:  DISPLAY  COURSE/LAB  SCHEDULING  SCREEN 


MODULE:  FORMAT  TO  FILE  SCREEN 

PURPOSE:  To  format  the  CRT  screen  for  filename  entry. 

USES :  N/A 

RETURNS :  FILE  SCREEN 

FUNCTIONAL  DETAILS: 

1.  Format  screen  with  filename  entry  data  and 
prompt . 

CALLED  BY:  DISPLAY  FILE  SCREEN 


MODULE  :  FORMAT  TO  HELP  SCREEN 

PURPOSE:  To  format  the  CRT  screen  for  help  instructions. 

USES :  HELP  INSTRUCTIONS 

RETURNS:  HELP  SCREEN 

FUNCTIONAL  DETAILS: 

1.  Format  screen  with  given  HELP  INSTRUCTIONS. 
CALLED  BY:  DISPLAY  HELP  SCREEN 


MODULE  : 


FORMAT  TO  PASSWORD  SCREEN 


PURPOSE:  To  format  the  CRT  screen  for  password  entry. 

USES:  N/A 

RETURNS:  PASSWORD  SCREEN 

FUNCTIONAL  DETAILS: 

1.  Format  screen  with  password  entry  data  and 
prompt . 

CALLED  BY:  DISPLAY  PASSWORD  SCREEN 


MODULE: 


FORMAT  TO  PRINT  SCREEN 


PURPOSE:  To  format  the  CRT  screen  for  print  item  query. 

USES:  N/A 

RETURNS:  PRINT  SCREEN 

FUNCTIONAL  DETAILS: 

1.  Format  screen  with  item  query  data  and  prompt. 
CALLED  BY:  DISPLAY  PRINT  SCREEN 


MODULE: 


FORMAT  TO  SCHEDULE  CONFLICT/ALTERNATIVE  SCREEN 


PURPOSE:  To  format  the  screen  for  ALTERNATIVE  SELECTION. 

USES:  N/A 

RETURNS:  SCHEDULE  CONFLICT/ALTERNATIVES  SCREEN 

FUNCTIONAL  DETAILS: 

1.  Format  screen  for  selection  of  displayed 
alternative  TIME  PERIODS. 

CALLED  BY:  DISPLAY  SCHEDULE  CONFLICT/ALTERNATIVES  SCREEN 


MODULE) 


FORMAT  TO  SCHEDULE  RECORD  SCREEN 


PURPOSE  t 

USES: 

RETURNS: 

FUNCTIONAL 


To  format  the  CRT  screen  for  schedule  record 
queries  by  system  user. 


N/A 

SCHEDULE  RECORD  SCREEN 

DETAILS : 

1.  Format  screen  with  schedule  record  query  dqtq 
and  prompt . 


CALLED  BY:  DISPLAY  SCHEDULE  RECORD  SCREEN 


MODULE: 


FORMAT  TO  TRANSACTION  SCREEN 


PURPOSE:  To  format  the  CRT  screen  for  TRANSACTION  entry. 

USES:  N/A 

RETURNS:  TRANSACTION  SCREEN 

FUNCTIONAL  DETAILS: 

1.  Format  screen  with  TRANSACTION  entry  data  and 
prompt . 

CALLED  BY:  DISPLAY  TRANSACTION  SCREEN 


MODULE: 


GET  ALTERNATIVE  SELECTION 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


TO  get  an  ALTERNATIVE  SELECTION,  from  a  list  of 
ALTERNATIVES,  entered  by  the  system  user. 

N/A 

ALTERNATIVE  SELECTION 

DETAILS:  (Pre- defined) 

1.  Enter  ALTERNATIVE  SELECTION. 


CALLED  BY:  VALIDATE  AND  ECHO  SCHEDULE  CONFLICT/ ALTERNATIVES 

SCREEN 


MODULE: 


GET  DATE 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


To  get  the  current  date  from  the  operating  system. 
N/A 

DATE 

DETAILS:  ( Pre - defined) 

1.  Get  current  date  from  operating  system. 


SAVE  TO  PERTINENT  FILE /RECORD 
UPDATE  SCHEDULE  RECORDS 


MODULE: 


GET  FILE  NAME 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  get  a  FILENAME  from  system  user. 


N/A 

FILENAME 

DETAILS:  (Pre- defined) 
1.  Enter  FILENAME. 


CALLED  BY:  VALIDATE  AND  ECHO  FILE  SCREEN 


MODULE : 


GET  ITEM  PRINT  QUERY 


PURPOSE: 

USES: 

RETURNS: 

FUNCTIONAL 


To  get  a  query  on  an  item  to  print  from  the  system 
user. 

N/A 

ITEM  QUERY 

DETAILS:  (Pre- defined) 

1.  Enter  ITEM  PRINT  QUERY. 


CALLED  BY:  VALIDATE  AND  ECHO  PRINT  SCREEN 


MODULE  : 


GET  ROOM 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  get  a  ROOM,  for  a  given  course/lab,  entered  by 
the  system  user. 

N/A 

ROOM  NUMBER 
BUILDING  CODE 

DETAILS:  (Pre- defined) 

1.  Enter  BUILDING  CODE  and  ROOM  NUMBER. 


CALLED  BY:  VALIDATE  AND  ECHO  COURSE/LAB  SCHEDULING  SCREEN 


MODULE: 


GET  SCHEDULE  CHANGES 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  get  the  schedule  information  changes  for 
updating  schedule  records. 

N/A 

SCHED  INFO 

DETAILS : 

1.  Get  the  schedule  information  changes  for 
particular  course  and  its  related  SCHED 
RECORDS . 

2.  Return  the  schedule  info. 


CALLED  BY:  UPDATE  SCHEDULE  RECORDS 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


GET  SCHEDULE  RECORD  QUERY 

To  get  a  SCHEDULE  RECORD  QUERY  from  the  system 
user. 


N/A 

SCHEDULE  RECORD  QUERY 

DETAILS:  (Pre- defined) 

1.  Enter  SCHEDULE  RECORD  QUERY 


CALLED  BY:  VALIDATE  AND  ECHO  COURSE/LAB  SCHEDULING  SCREEN 


MODULE: 


GET  TIME  PERIOD 


PURPOSE: 

USES: 

RETURNS: 

FUNCTIONAL 


To  get  a  TIME  PERIOD,  for  a  given  course/lab, 
entered  by  the  system  user. 

N/A 

DAY 

TIME 

DETAILS:  { Pre - defined) 

1.  Enter  DAY (s)  and  TIME (s). 


CALLED  BY:  VALIDATE  AND  ECHO  COURSE/LAB  SCHEDULING  SCREEN 


MODULE*  GET  TRANSACTION 

PURPOSE:  To  get  TRANSACTION  from  system  user. 

USES :  N/A 

RETURNS  s  TRANSACTION 

FUNCTIONAL  DETAILS:  (Pre- defined) 

1.  Enter  TRANSACTION. 

CALLED  BY:  VALIDATE  AND  ECHO  TRANSACTION  SCREEN 


MODULE: 


GET  USER  PASSWORD 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  get  the  password  from  the  system  user. 
N/A 

USER  PASSWORD 

DETAILS:  (Pre- defined) 

1.  Enter  USER  PASSWORD. 


CALLED  BY:  VALIDATE  AND  ECHO  PASSWORD  SCREEN 


MODULE * 


GET  VALID  DATA  MAINTENANCE  TRANSACTION 


PURPOSE : 

USES : 

RETURNS: 

FUNCTIONAL 


To  get  a  valid  data  maintenance  transaction. 
N/A 

VALID  TRANSACTION 


DETAILS : 

Begin 

Call  DISPLAY  TRANSACTION  SCREEN  (DATA  MAINTENANCE 

TRANSACTIONS) 

Call  VALIDATE  AND  ECHO  TRANSACTION  SCREEN 
RETURN  VALID  TRANSACTION 
End 


CALLED  BY:  SCHEDULING  DATA  MAINTENANCE 


MODULE: 


GET  VALID  EVENT/COURSE  SCHEDULING  TRANSACTION 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


CALLED  BY: 


To  get  a  valid  event/course  scheduling  transaction. 
N/A 

VALID  TRANSACTION 


DETAILS : 

Begin 

Call  DISPLAY  TRANSACTION  SCREEN  (EVENT/ COURSE 

TRANSACTIONS ) 

Call  VALIDATE  AND  ECHO  TRANSACTION  SCREEN 
Return  VALID  TRANSACTION 
End 


MANAGE  EVENT/COURSE  SCHEDULING 


MODULE: 


GET  VALID  FILE 


PURPOSE: 

USES: 

RETURNS : 

FUNCTIONAL 

CALLED  BY: 


To  get  a  valid  file  to  update. 


N/A 

VALID  FILE 


DETAILS : 

Begin 

Call  DISPLAY  FILE  SCREEN 
Call  VALIDATE  AND  ECHO  FILE  SCREEN 
RETURN  VALID  FILE 
End 


UPDATE  DATABASE  FILES 
REVIEW  OLD  SCHEDULE  FILE 
DELETE  SCHEDULE  FILE 


MODULE: 


GET  VALID  FILE  NAME 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  get  a  VALID  FILE  NAME  for  a  newly  created  fil 
N/A 

VALID  FILE  NAME 


DETAILS : 

Begin 

Call  DISPLAY  FILE  SCREEN 

Call  VALIDATE  AND  ECHO  FILE  SCREEN 

Return  VALID  FILE  NAME 

End 


CALLED  BY:  SAVE  TO  MASTER  SCHEDULE  FILE 


MODULE 


GET  VALID  FILE  UPDATE  TRANSACTION 


PURPOSE  s 

USES: 

RETURNS: 

FUNCTIONAL 


To  get  a  valid  file  update  transaction. 


N/A 

VALID  TRANSACTION 


DETAILS : 

Begin 

Call  DISPLAY  TRANSACTION  SCREEN  (UPDATE 

TRANSACTIONS) 

Call  VALIDATE  AND  ECHO  TRANSACTION  SCREEN 
Return  VALID  TRANSACTION 
End 


CALLED  BY 


UPDATE  DATABASE  FILE 


MODULE: 

PURPOSE: 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


GET  VALID  ITEM  TO  PRINT 

To  get  a  valid  file,  record  or  report  to  print. 
N/A 

VALID  ITEM 


DETAILS: 

Begin 

Call  DISPLAY  PRINT  SCREEN 
Call  VALIDATE  AND  ECHO  PRINT  SCREEN 
Return  VALID  ITEM 
End 


PRINT  FILE,  RECORD,  REPORT 


MODULE 


GET  VALID  NPS  SCHEDULING  SYSTEM  TRANSACTION 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


To  get  a  valid  NPS  Scheduling  System  transaction. 
N/A 

VALID  TRANSACTION 


DETAILS : 

Begin 

Call  DISPLAY  TRANSACTION  SCREEN  (NPS3 

TRANSACTIONS ) 

Call  VALIDATE  AND  ECHO  TRANSACTION  SCREEN 
Return  VALID  TRANSACTION 
End 


NPS  SCHEDULING  SYSTEM 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


GET  VALID  PASSWORD 

To  get  a  valid  password  from  the  user,  in  order  to 
allow  the  user  to  enter  the  NPS  scheduling  system. 


N/A 


ENTER 


DETAILS : 

Begin 

Call  DISPLAY  PASSWORD  SCREEN 
Call  VALIDATE  AND  ECHO  PASSWORD  SCREEN 
If  flag  =  VALID  PASSWORD 
Return  ENTER 
End  if 
End 


CALLED  BY:  NPS  SCHEDULING  SYSTEM 


MODULE: 

PURPOSE: 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


GET  VALID  SCHEDULE  RECORD  TO  UPDATE 

To  get  the  VALID  SCHEDULE  RECORDS  the  system  user 
wishes  to  update. 


N/A 

VALID  SCHEDULE  RECORDS 


DETAILS : 

Begin 

Call  DISPLAY  SCHEDULE  RECORD  SCREEN 
Call  VALIDATE  AND  ECHO  SCHEDULE  RECORD  SCREEN 
Return  VALID  SCHEDULE  RECORDS 
End 


UPDATE  SCHEDULE  FILE 


MODULE: 


GET  VALID  TIME  PERIOD  AND  ROOM 


PURPOSE : 


USES: 


RETURNS: 


FUNCTIONAL 


CALLED  BY: 


To  get  a  VALID  TIME  PERIOD  and  VALID  ROOM  for  a 
given  course/course  segment  and  lab. 


SCREEN  INDICATOR 

COURSE  SEGMENT  SCREEN  INFO 


VALID  TIME  PERIOD 
VALID  ROOM 


DETAILS : 

Begin 

Call  DISPLAY  COURSE/LAB  SCHEDULING  SCREEN 

(COURSE  SEGMENT  SCREEN  INFO,  SCREEN  INDICATOR) 

Call  VALIDATE  AND  ECHO  COURSE/LAB  SCHEDULING 

SCREEN 

Return  (VALID  TIME  PERIOD,  VALID  ROOM) 

End 


SCHEDULE  REFRESHER  COURSES 

SCHEDULE  COURSES  w/  REQUIRED  TIME  PERIOD 

SCHEDULE  COURSES  w/  REQUIRED  TIME  PERIOD  FOR 

INSTRUCTOR 

SCHEDULE  COURSES  w/  LARGE  #  OF  STUDENTS 
SCHEDULE  COURSES  TAUGHT  BY  DEAN/CHAIRMAN 
SCHEDULE  SIMULTANEOUS  SCHEDULED  COURSES 
SCHEDULE  ACCELERATED  COURSES 

SCHEDULE  COURSES  W/  DESIGNATED  STUDENT  COURSE  GRPS 
SCHEDULE  COURSES  REQUIRING  SPECIAL  ROOMS 
SCHEDULE  COURSES  W/  3  HOUR  LABS 
SCHEDULE  COURSES  W/  REQUIRED  LAB  ROOM  AND  TIME 

PERIOD 

SCHEDULE  COURSES  W/  DIVERSITY  OF  MAJORS 
SCHEDULE  COURSES  W/  TEACHING  TEAMS 
SCHEDULE  REMAINING  COURSES 


MODULE:  manage  event/course  scheduling 

PURPOSE:  To  manage  the  scheduling  of  semi-permanant  events 

and  courses. 


USES:  N/A 

RETURNS :  N/A 


FUNCTIONAL  DETAILS: 

Begin 

Loop 

Call  GET  VALID  EVENT/COURSE  SCHEDULING 

TRANSACTION 

Case  VALID  TRANSACTION 

When  VALID  TRANSACTION  =  CREATE 
Call  CREATE  NEW  SCHEDULES 
When  VALID  TRANSACTION  =  REVIEW 
Call  REVIEW  OLD  SCHEDULE  FILE 
when  VALID  TRANSACTION  =  PRINT 
Call  PRINT  FILE,  RECORD,  REPORT 
When  VALID  TRANSACTION  =  DELETE 
Call  DELETE  SCHEDULE  FILE 
End  Case 
End  loop 
End 


CALLED  BY:  NPS  SCHEDULING  SYSTEM 


MODULE:  MODIFY  DATA  RECORD 

PURPOSE:  To  modify  a  data  record  in  the  given  file. 

USES:  VALID  FILE 

RETURNS :  N/A 

FUNCTIONAL  DETAILS:  (Pre- defined) 

1.  Modify  a  record  in  the  VALID  FILE. 

CALLED  BY:  UPDATE  DATABASE  FILES 


MODULE:  NPS  SCHEDULING  SYSTEM 


PURPOSE:  To  coordinate  the  scheduling  of  NPS  events,  courses 
and  final  exams,  and  associated  schedules,  reports, 
graphs  and  data  maintenance. 

USES:  N/A 

RETURNS :  N/A 

FUNCTIONAL  DETAILS: 

Begin 

CALL_GET  VALID  PASSWORD 
If  flag  =  ENTER 
Loop 

Call  GET  VALID  NPS  SCHEDULING  SYSTEM 
TRANSACTION 

Case  VALID  TRANSACTION 

When  VALID  TRANSACTION  =  DATA  MAINTENANCE 
Call  SCHEDULING  DATA  MAINTENANCE 
When  VALID  TRANSACTION  =  EVENT/COURSE 

SCHEDULING 

Call  MANAGE  EVENT/COURSE  SCHEDULING 
When  VALID  TRANSACTION  =  FINAL  EXAM 

SCHEDULING 

Call  MANAGE  FINAL  EXAM  SCHEDULING 
When  VALID  TRANSACTION  =  MASTER  INSTRUCTION 

SCHEDULE 

Call  MANAGE  MASTER  INSTRUCION  SCHEDULE 
When  VALID  TRANSACTION  =  DATA  GRAPH 
Call  MANAGE  SCHEDULING  DATA  GRAPH 
End  case 
End  loop 
End  if 
End 


CALLED  BY:  N/A 


MODULE: 


PRINT 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  print  the  VALID  ITEM. 
VALID  ITEM 

N/A 

DETAILS:  (Pre- defined) 

1.  Print  the  VALID  ITEM. 


CALLED  BY:  PRINT  FILE,  RECORD,  REPORT 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


PRINT  FILE,  RECORD,  REPORT 


To  coordinate  printing  of  files,  records  and 
reports . 

N/A 


N/A 


DETAILS : 

Begin 

Loop 

Call  GET  VALID  ITEM  TO  PRINT 
Call  PRINT  (ITEM) 

End  loop 
End 


SCHEDULING  DATA  MAINTENANCE 
MANAGE  EVENT/COURSE  SCHEDULING 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


PUT  ALTERNATIVE  SELECTION  TO  SCHED  RECORDS 

To  put  the  alternative  selected  to  the  related 
SCHED  RECORDS. 

SCHED  RECORDS 
UPDATED  SCHED  INFO 

UPDATED  SCHED  RECORDS 


DETAILS:  (Pre- defined) 

1.  For  each  SCHED  RECORD,  put  appropriate  SCHED 
INFO  in  the  slot  where  UPDATED  SCHED  INFO. TIME 
PERIOD  =  SCHED  RECORD. TIME  PERIOD. 


RESOLVE  SCHEDULE  RECORD  CONFLICTS 
RESOLVE  UPDATE  CONFLICTS 


MODULE: 


PUT  COURSE/LAB  SCHEDULING  SCREEN 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


To  display  the  COURSE/LAB  SCHEDULING  SCREEN  on  the 
CRT. 


COURSE/LAB  SCHEDULING  SCREEN 
INVALID  TIME  PERIOD  MESSAGE 
INVALID  ROOM  MESSAGE 


N/A 


DETAILS:  ( Pre -  defined) 

1.  Display  the  COURSE/LAB  SCHEDULING  SCREEN  on  the 

CRT  screen. 

2.  Display  INVALID  TIME  PERIOD  MESSAGE  or  INVALID 
ROOM  MESSAGE  when  appropriate. 


DISPLAY  COURSE/LAB  SCHEDULING  SCREEN 
VALIDATE  AND  ECHO  COURSE/LAB  SCHEDULING  SCREEN 


MODULE 


PUT  FILE  SCREEN 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


To  display  the  FILE  SCREEN  on  the  CRT. 

FILE  SCREEN 
INVALID  FILE  MESSAGE 

N/A 

DETAILS:  (Pre- defined) 

1.  Display  the  FILE  SCREEN  on  the  CRT  screen. 

2.  DISPLAY  INVALID  FILE  MESSAGE  when  appropriate. 


DISPLAY  FILE  SCREEN 
VALIDATE  AND  ECHO  FILE  SCREEN 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


PUT  HELP  SCREEN 

To  display  the  help  screen  on  the  CRT. 

HELP  SCREEN 
N/A 

DETAILS:  (Pre-def ined) 

1.  Display  the  given  HELP  SCREEN  on  the  CRT 
screen. 


CALLED  BY:  DISPLAY  HELP  SCREEN 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


PUT  PASSWORD  SCREEN 


To  display  the  password  screen  on  the  CRT. 


PASSWORD  SCREEN 

INVALID  PASSWORD  MESSAGE  1 

INVALID  PASSWORD  MESSAGE  2 


N/A 


DETAILS:  (Pre-def ined) 

1.  Display  the  password  screen  on  the  CRT  screen. 

2.  DISPLAY  INVALID  PASSWORD  MESSAGE  1  or  INVALID 
PASSWORD  MESSAGE  2  when  apprpriate. 


DISPLAY  PASSWORD  SCREEN 
VALIDATE  AND  ECHO  PASSWORD  SCREEN 


MODULE 


PUT  PRINT  SCREEN 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


To  display  the  print  screen  on  the  CRT. 

PRINT  SCREEN 
INVALID  PRINT  MESSAGE 

N/A 

DETAILS:  (Pre- defined) 

1.  Display  the  PRINT  SCREEN  on  the  CRT  screen. 

2.  Display  INVALID  PRINT  MESSAGE  when  appropriate. 

DISPLAY  PRINT  SCREEN 
VALIDATE  AND  ECHO  PRINT  SCREEN 


MODULE: 


PUT  SCHEDULE  CONFLICT/ALTERNATIVES  SCREEN 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


CALLED  BY: 


To  display  the  SCHEDULE  CONFLICT/ALTERNATIVES 
SCREEN  on  the  CRT. 


SCHEDULE  CONFLICT/ALTERNATIVES  SCREEN 
INVALID  SELECTION  MESSAGE 


N/A 


DETAILS:  (Pre- defined) 

1.  Display  the  SCHEDULE  CONFLICT/ALTERNATIVES 
SCREEN  on  the  CRT  screen. 

2.  Display  INVALID  SELECTION  MESSAGE  when 
appropriate . 


DISPLAY  SCHEDULE  CONFLICT/ALTERNATIVES  SCREEN 
VALIDATE  AND  ECHO  SCHEDULE  CONFLICT/ALTERNATIVES 

SCREEN 


MODULE:  PUT  SCHEDULE  RECORD  SCREEN 

PURPOSE:  To  display  the  SCHEDULE  RECORD  SCREEN  on  the  CRT. 

USES:  SCHEDULE  RECORD  SCREEN 

INVALID  SCHEDULE  RECORD  MESSAGE 

RETURNS :  N/A 

FUNCTIONAL  DETAILS:  ( Pre - defined) 

1.  Display  the  SCHEDULE  RECORD  SCREEN  on  the  CRT 
screen. 

2.  Display  INVALID  SCHEDULE  RECORD  MESSAGE  when 
appropriate . 

CALLED  BY:  DISPLAY  SCHEDULE  RECORD  SCREEN 

VALIDATE  AND  ECHO  SCHEDULE  RECORD  SCREEN 


MODULE: 


PUT  TRANSACTION  SCREEN 


PURPOSE:  To  display  the  TRANSACTION  SCREEN  on  the  CRT 

screen. 


USES:  TRANSACTION  SCREEN 

INVALID  TRANSACTION  MESSAGE 


RETURNS :  N/A 


FUNCTIONAL  DETAILS:  (Pre- defined) 

1.  Display  the  TRANSACTION  SCREEN  on  the  CRT 
screen. 

2.  Display  the  INVALID  TRANSACTION  MESSAGE  when 
appropriate . 


CALLED  BY:  DISPLAY  TRANSACTION  SCREEN 

VALIDATE  AND  ECHO  TRANSACTION  SCREEN 


MODULE: 


READ  COURSE  FILE 


PURPOSE : 

USES: 


RETURNS: 

FUNCTIONAL 


CALLED  BY: 


To  read  the  COURSE  FILE. 


NULL  STATUS 
REFRESHER  COURSE 
COURSE  REQUIRED  TIME 
INSTRUC  REQUIRED  TIME 
COURSE  TYPE 
COURSE  NUMBER 
SIMULTANEOUS  SCHED  COURSE 
ACCELERATED  COURSE 
SPECIAL  ROOM  REQUIREMENT 
LAB  HRS 

REQUIRED  LAB  ROOM 
DIVERSITY  OF  MAJORS 

COURSE  INFO 


DETAILS:  (Pre- defined) 

1.  Read  the  next  COURSE  RECORD,  until  EOF  where 
the  given  data  matches  the  COURSE  RECORD 
data  and  where  COURSE  RECORD . STATUS  is 

NULL  STATUS. 

2.  Read  the  next  COURSE  RECORD,  until  EOF,  where 
COURSE  RECORD . COURSE  TYPE  and  COURSE 
RECORD. COURSE  NUMBER  equals  the  given  COURSE 
TYPE  and  COURSE  NUMBER,  respectively. 

3.  Return  the  desired  COURSE  INFO. 


SCHEDULE  REFRESHER  COURSES 

SCHEDULE  COURSES  w/  REQUIRED  TIME  PERIOD 

SCHEDULE  COURSES  w/  REQUIRED  TIME  PERIOD  FOR 

INSTRUCTOR 

SCHEDULE  COURSES  w/  LARGE  #  OF  STUDENTS 
SCHEDULE  COURSES  TAUGHT  BY  DEAN/CHAIRMAN 
SCHEDULE  SIMULTANEOUS  SCHEDULED  COURSES 
SCHEDULE  ACCELERATED  COURSES 

SCHEDULE  COURSES  W/  DESIGNATED  STUDENT  COURSE  GRPS 
SCHEDULE  COURSES  REQUIRING  SPECIAL  ROOMS 
SCHEDULE  COURSES  W/  3  HOUR  LABS 
SCHEDULE  COURSES  W/  REQUIRED  LAB  ROOM  AND  TIME 

PERIOD 

SCHEDULE  COURSES  W/  DIVERSITY  OF  MAJORS 
SCHEDULE  COURSES  W/  TEACHING  TEAMS 
SCHEDULE  REMAINING  COURSES 


MODULE: 


PURPOSE  s 

USES: 

RETURNS: 

FUNCTIONAL 


READ  COURSE  SEGMENT  FILE 


To  read  the  COURSE  SEGMENT  FILE. 


COURSE  TYPE 
COURSE  NUMBER 
NULL  STATUS 
SEGMENT  STUDENTS 
INSTRUC  CODE 

DESIGNATED  STUDENT  COURSE  GRP 
TEACHING  TEAM 


COURSE  SEGMENT  RECORD 
EOF 


DETAILS:  ( Pre- defined) 

Begin 

Read  next  COURSE  SEGMENT  RECORD 
For  COURSE  SEGMENT  RECORD . COURSE  TYPE  =  COURSE 
TYPE  and  COURSE  SEGMENT  RECORD . COURSE 
NUMBER  =  COURSE  NUMBER 
Return  COURSE  SEGMENT  RECORD 
For  COURSE  SEGMENT  RECORD . STATUS  »  NULL  STATUS 
and  COURSE  SEGMENT. SEGMENT  STUDENTS  >= 

SEGMENT  STUDENTS 

Return  COURSE  SEGMENT  RECORD 
For  COURSE  SEGMENT  RECORD . INSTRUC  CODE  =  INSTRUC 
CODE  and  COURSE  SEGMENT  RECORD . STATUS  = 

NULLSTATUS 

Return  COURSE  SEGMENT  RECORD 
For  COURSE  SEGMENT  RECORD . STATUS  «  NULL  STATUS 
and  COURSE  SEGMENT. DESIGNATED  STUDENT 

COURSE  GRP  not  null 
Return  COURSE  SEGMENT  RECORD 
For  COURSE  SEGMENT  RECORD . STATUS  =  NULL  STATUS 
and  COURSE  SEGMENT. TEACHING  TEAM  not  null 
Return  COURSE  SEGMENT  RECORD 
For  EOF 

Return  EOF 


End 


CALLED  BY:  SCHEDULE  REFRESHER  COURSES 

SCHEDULE  COURSES  w/  REQUIRED  TIME  PERIOD 
SCHEDULE  COURSES  w/  REQUIRED  TIME  PERIOD  FOR 

INSTRUCTOR 

SCHEDULE  COURSES  w/  LARGE  #  OF  STUDENTS 
SCHEDULE  COURSES  TAUGHT  BY  DEAN/CHAIRMAN 
SCHEDULE  SIMULTANEOUS  SCHEDULED  COURSES 
SCHEDULE  ACCELERATED  COURSES 

SCHEDULE  COURSES  W/  DESIGNATED  STUDENT  COURSE  GRPS 
SCHEDULE  COURSES  REQUIRING  SPECIAL  ROOMS 
SCHEDULE  COURSES  W/  3  HOUR  LABS 
SCHEDULE  COURSES  W/  REQUIRED  LAB  ROOM  AND  TIME 

PERIOD 

SCHEDULE  COURSES  W/  DIVERSITY  OF  MAJORS 
SCHEDULE  COURSES  W/  TEACHING  TEAMS 
SCHEDULE  REMAINING  COURSES 


MODULE: 


READ  FILE 


PURPOSE:  To  read  the  given  file. 

USES :  FILENAME 

RETURNS :  FILE 

FUNCTIONAL  DETAILS:  (Pre- defined) 

1.  Read  the  FILE  that  matches  the 
FILENAME  given. 

CALLED  BY:  VALIDATE  AND  ECHO  FILE  SCREEN 


MODULE : 


READ  HELP  INSTRUCTION  FILE 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


To  read  the  file  containing  help  instructions  for 
system  screen  displays. 


HELP  SCREEN  INDICATOR 

HELP  INSTRUCTIONS 

DETAILS:  ( Pre - defined) 

1.  Read  the  file  containing  the  HELP  INSTRUCTIONS. 

2  .  RETURN  the  HELP  INSTRUCTIONS  for  the  given  HELP 
SCREEN  INDICATOR. 

DETERMINE  HELP  INSTRUCTIONS 


MODULE: 


READ  INSTRUC  SCHED  FILE 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  read  the  INSTRUC  SCHED  FILE  and  find  the  related 
INSTRUC  SCHED  RECORDS. 


INSTRUC  CODE 


INSTRUC  SCHED  RECORD 
EOF  (flag) 


DETAILS:  (Pre- defined) 

1.  Read  the  INSTRUC  SCHED  FILE  and  return  the 
related  INSTRUC  SCHED  RECORDS  pertaining  to 
the  given  INSTRUC  CODE. 

2.  Read  the  Instructor  schedule  file  and  return 
all  the  INSTRUC  SCHED  RECORDS  for  saving  to 
master  schedule  file. 


DETERMINE  MBRSHP  SCHEDS  AND  ROOM  SCHED 
DETERMINE  RELATED  SCHEDULE  RECORD  COMFLICTS 
SAVE  TO  MASTER  SCHEDULE  FILE 


CALLED  BY: 


MODULE: 

READ  INSTRUCTOR  FILE 

PURPOSE : 

To  read  the  Instructor  file. 

USES: 

DEPT  CHAIR  OR  DEAN 

RETURNS: 

FACULTY  CODE 

DEPT  LTR  CODE 

FUNCTIONAL  DETAILS:  { Pre - defined) 

1.  Read  the  next  Instructor  record  and  return  the 
FACULTY  CODE  and  DEPT  LTR  CODE  for  the 
Instructor  that  has  a  DEPT  CHAIR  OR  DEAN 
indicator . 


CALLED  BY 


SCHEDULE  COURSES  TAUGHT  BY  DEAN/CHAIRMAN 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


READ  M/F  E-Z  CLASS  DEMAND  LIST  FILE 

To  read  the  mainframe  file  containing  course 
information. 

N/A 


COURSE  TYPE 
COURSE  NUMBER 
LECT  HRS 
LAB  HRS 


DETAILS:  ( Pre - def ined) 

1.  Read  the  mainframe  file  containing  course 
information. 


UPDATE  COURSE /COURSE  SEGMENT  FILES 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


READ  M/F  PROFESSOR  LISTING  FILE 


To  read  the  mainframe  file  containing  Faculty 
information. 


N/A 


FACULTY  NAME 
FACULTY  CODE 
DEPT  LTR  CODE 


DETAILS:  ( Pre -  defined) 

1.  Read  the  mainframe  file  containing  Faculty 
information. 


CALLED  BY:  UPDATE  FACULTY  FILE 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


READ  M/F  SCG  SECT  FILE 


To  read  the  mainframe  file  containing  STUDENT 
COURSE  GRP  records. 


COURSE  TYPE 
COURSE  NUMBER 


SECT  SCG  RECORD 
EDF  (flag) 

SCG  CARD  NUMBER 


DETAILS:  ( Pre - defined) 

1.  Read  the  mainframe  file  containing  STUDENT 
COURSE  GRP  records. 


UPDATE  STUDENT  COURSE  CROUP  FILE 
UPDATE  COURSE/COURSE  SEGMENT  FILES 


MODULE: 


read  m/f  student  sect  file 


PURPOSE: 

USES: 

RETURNS: 

FUNCTIONAL 


To  read  the  mainframe  file  containing  student 
records . 


N/A 

EOF 

SECT  STUDENT  RECORD 
DETAILS:  (Pre- defined) 

1.  Read  the  mainframe  file  containing  student 
records . 


CALLED  BY: 


UPDATE  STUDENT  FILE 


MODULE 


READ  ROOM  SCHED  FILE 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


CALLED  BY: 


To  read  the  ROOM  SCHED  FILE  and  find  the  related 
ROOM  SCHED  RECORD. 

ROOM 


ROOM  SCHED  RECORD 
EOF  (flag) 


DETAILS:  (Pre- defined) 

1 .  Read  the  ROOM  SCHED  FILE  and  return  the  related 
ROOM  SCHED  RECORD  pertaining  to  the  given 
ROOM. 

2.  Read  the  ROOM  schedule  file  and  return  all  ROOM 
SCHED  RECORDS  to  save  to  master  schedule  file. 


DETERMINE  MBRSHP  SCHEDS  AND  ROOM  SCHED 
DETERMINE  RELATED  SCHEDULE  RECORD  CONFLICTS 
SAVE  TO  MASTER  SCHEDULE  FILE 


MODULE 


READ  SCG  SCHED  FILE 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


CALLED  BY: 


To  read  the  SCG  SCHED  FILE  and  find  all  related 
SCG  SCHED  RECORDS. 


DESIGNATED  STUDENT  COURSE  GRP'S 


SCG  SCHED  RECORD 
EOF  (flag) 


DETAILS:  (Pre- defined) 

1.  Read  the  SCG  SCHED  FILE  and  return  all  the 
related  SCG  SCHED  RECORDS  pertaining  to  the 
given  DESIGNATED  STUDENT  COURSE  GRP'S. 

2.  Read  the  SCG  schedule  file  and  return  all  SCG 
SCHED  RECORDS  to  be  saved  to  master  schedule 
file. 


DETERMINE  MBRSHP  SCHEDS  AND  ROOM  SCHED 
DETERMINE  RELATED  SCHEDULE  RECORD  CONFLICTS 
SAVE  TO  MASTER  SCHEDULE  FILE 


MODULE: 


READ  SCHEDULE  RECORDS 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  read  the  schedule  records  pertaining  to  the 
SCHEDULE  RECORD  QUERY. 


SCHEDULE  RECORD  QUERY 


SCHED  RECORDS 
NOT  FOUND  (flag) 


DETAILS:  (Pre- defined) 

1.  Read  the  SCHED  RECORDS  that  pertain  to  the 
given  SCHEDULE  RECORD  QUERY. 


CALLED  BY:  VALIDATE  AND  ECHO  SCHEDULE  RECORD  SCREEN 


MODULE: 


READ  SCREEN 


PURPOSE:  To  read  the  screen  currently  displayed  on  the  CRT. 


USES :  N/A 


RETURNS:  FLAG  TYPE  (flag) 

PRINT  SCREEN 

PASSWORD  SCREEN 

COURSE/LAB  SCHEDULING  SCREEN 

PASSWORD  HELP  SCREEN 

TRANSACTION  SCREEN 

FILE  SCREEN 

SCHEDULE  CONFLICT/ALTERNATIVES  SCREEN 
SCHEDULE  RECORD  SCREEN 


FUNCTIONAL  DETAILS:  (Pre - defined) 

1.  READ  the  screen  and  return  user  designated 
FLAG  TYPE  entry. 


CALLED  BY:  VALIDATE  AND  ECHO  PASSWORD  SCREEN 
DETERMINE  HELP  INSTRUCTIONS 
VALIDATE  AND  ECHO  TRANSACTION  SCREEN 
VALIDATE  AND  ECHO  FILE  SCREEN 
VALIDATE  AND  ECHO  PRINT  SCREEN 

VALIDATE  AND  ECHO  COURSE/LAB  SCHEDULING  SCREEN 
VALIDATE  AND  ECHO  SCHEDULE  CONFLICT/ALTERNATIVES 

SCREEN 

VALIDATE  AND  ECHO  SCHEDULE  RECORD  SCREEN 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 


RT  '  SEMI -PERM  EVENT  FILE 

To  read  the  SEMI -PERM  EVENT  FILE. 
N/A 

EOF  (flag) 

SEMI -PERM  EVENT  RECORD 


FUNCTIONAL  DETAILS:  ( Pre -  defined) 

1.  Read  the  SEMI -PERM  EVENT  FILE  and  return  SEMI- 
PERM  EVENT  RECORD  each  time  called  until  EOF 
is  reached. 


CALLED  BY:  DETERMINE  SEMI -PERM  EVENT  AND  EVENT  MBRSHP 


MODULE*  READ  SEMI -PERM  EVENT  MBRSHP  FILE 

PURPOSE*  TO  read  the  SEMI -PERM  EVENT  MBRSHP  FILE 

USES  *  EVENT  TYPE 

EVENT  NAME 

RETURNS*  MBRSHP 

FUNCTIONAL  DETAILS*  (Pre-def ined) 

1.  Read  the  SEMI -PERM  EVENT  MBSHP  FILE  and  return 
all  the  MBRSHP  RECORDS  that  relate  to  the 
given  event . 


CALLED  BY*  DETERMINE  SEMI -PERM  EVENT  AND  EVENT  MBRSHP 


MODULE:  READ  SYSTEM  PASSWORD  FILE 

PURPOSE:  To  read  the  system  password. 

USES:  N/A 

RETURNS :  SYSTEM  PASSWORD 

FUNCTIONAL  DETAILS:  (Pre- defined) 

l.Read  the  file  containing  the  system  password. 

CALLED  BY:  VALIDATE  AND  ECHO  PASSWORD  SCREEN 


MODULE 


RESOLVE  SCHED  RECORD  CONFLICT 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  allow  the  system  user  to  resolve  TIME  PERIOD 
SCHEDULE  CONFLICTS. 


SCHED  INFO 


UPDATED  SCHED  RECORDS 
UPDATED  SCHED  INFO  . 


DETAILS : 

Begin 

Call  DETERMINE  RELATED  SCHEDULE  RECORD  CONFLICTS 

(SCHED  INFO) 

If  NO  CONFLICT  (flag)  is  returned 

Return  (UPDATED  SCHED  RECORDS,  SCHED  INFO  as 

UPDATED  SCHED  INFO) 

Else 

Call  SEARCH  for  ALTERNATIVES  (SCHED  RECORDS) 
Call  DISPLAY  SCHEDULE  CONFLICTS /ALTERNATIVES 

SCREEN  (ALTERNATIVES, 
SCHEDULE  CONFLICTS) 
Call  VALIDATE  AND  ECHO  SCHEDULE 

CONFLICT/ALTERNATIVESSCREEN 
SCHED  INFO. TIME  PERIOD  :=  VALID  ALTERNATIVE 

SELECTION 

UPDATED  SCHED  INFO  :=  SCHED  INFO 

Call  PUT  ALTERNATIVE  SELECTION  TO  SCHEDULE 

RECORDS  (UPDATED  SCHED 
INFO,  SCHED  RECORDS) 
Return  (UPDATED  SCHED  RECORDS,  UPDATED  SCHED 

INFO) 

End  if 
End 


CALLED  BY:  SCHEDULE  REFRESHER  COURSES 

SCHEDULE  COURSES  w/  REQUIRED  TIME  PERIOD 
SCHEDULE  COURSES  w/  REQUIRED  TIME  PERIOD  FOR 

INSTRUCTOR 

SCHEDULE  COURSES  w/  LARGE  #  OF  STUDENTS 
SCHEDULE  COURSES  TAUGHT  BY  DEAN/CHAIRMAN 
SCHEDULE  SIMULTANEOUS  SCHEDULED  COURSES 
SCHEDULE  ACCELERATED  COURSES 

SCHEDULE  COURSES  W/  DESIGNATED  STUDENT  COURSE  GRPS 
SCHEDULE  COURSES  REQUIRING  SPECIAL  ROOMS 
SCHEDULE  COURSES  W/  3  HOUR  LABS 
SCHEDULE  COURSES  W/  REQUIRED  LAB  ROOM  AND  TIME 

PERIOD 

SCHEDULE  COURSES  W/  DIVERSITY  OF  MAJORS 
SCHEDULE  COURSES  W/  TEACHING  TEAMS 
SCHEDULE  REMAINING  COURSES 


MODULE 


RESOLVE  UPDATE  CONFLICTS 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  resolve  the  conflicts  pertaining  to  updates  made 
to  SCHED  RECORDS. 


SCHED  INFO 
SCHEDULE  CONFLICT 
SCHED  RECORDS 


UPDATED  SCHED  RECORDS 


DETAILS : 

Begin 

Call  SEARCH  FOR  ALTERNATIVES  (SCHED  RECORDS) 
Call  DISPLAY  SCHEDULE/ALTERNATIVES  SCREEN 

(ALTERNATIVES,  SCHEDULE  CONFLICT) 
Call  VALIDATE  AND  ECHO  SCHEDULE 

CONFLICT/ALTERNATIVES  SCREEN 
SCHED  INFO. TIME  PERIOD  :=  VALID  ALTERNATIVE 

SELECTION 

UPDATED  SCHED  INFO  :=  SCHED  INFO 

Call  PUT  ALTERNATIVE  SELECTION  TO  SCHEDULE 

RECORDS  (UPDATED  SCHED  INFO,  SCHED  RECORDS) 
Return  (UPDATED  SCHED  RECORDS) 

End 


CALLED  BY:  UPDATE  SCHEDULE  RECORDS 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


SAVE  TO  MASTER  SCHEDULE  FILE 

To  coordinate  saving  created  schedule  records  to  a 
master  schedule  file. 

N/A 

N/A 


DETAILS : 

Begin 

Call  GET  VALID  FILE  NAME 

Call  VALIDATE  AND  ECHO  FILE  SCREEN 

Call  READ  INSTRUC  SCHED  FILE 

Call  READ  ROOM  SCHED  FILE 

Call  READ  STUDENT  COURSE  GRP  SCHED  FILE 

Call  WRITE  MASTER  SCHEDULE  FILE  (VALID  FILE  NAME, 

SCHED  RECORDS) 

End 


CALLED  BY:  CREATE  NEW  SCHEDULES 


MODULE 


SAVE  TO  PERTINENT  FILE/RECORD 


PURPOSE: 

USES: 

RETURNS: 

FUNCTIONAL 


To  save  the  updated  records  and  information  to  the 
affected  files  and  records. 


UPDATED  SCHED  RECORDS 
VALID  TIME  PERIOD 
NO  OF  COURSE  SEGMENTS 


N/A 


DETAILS : 

Begin 

STATUS  :=  DONE 

If  UPDATED  SCHED  INFO. SEGMENT  NUMBER  =  NO  OF 

COURSE  SEGMENTS 

Call  UPDATE  COURSE  RECORD  (STATUS,  COURSE 

TYPE,  COURSE  NUMBER) 

Endif 

Call  UPDATE  COURSE  SEGMENT  RECORD  (STATUS, 

VALID  TIME  PERIOD, 
COURSE  TYPE,  COURSE  NUMBER) 

Call  GET  DATE 

Call  WRITE  STUDENT  COURSE  GRP  SCHED  FILE  (DATE, 

UPDATED  STUDENT  COURSE  GRP  SCHED 

RECORD) 

Call  WRITE  ROOM  SCHED  FILE  (DATE,  UPDATED  ROOM 

SCHEDRECORD) 

Call  WRITE  INSTRUC  SCHED  FILE  (DATE,  UPDATED 

INSTRUC  SCHED  RECORD) 


End 


CALLED  BY:  SCHEDULE  REFRESHER  COURSES 

SCHEDULE  COURSES  w/  REQUIRED  TIME  PERIOD 
SCHEDULE  COURSES  w/  REQUIRED  TIME  PERIOD  FOR 

INSTRUCTOR 

SCHEDULE  COURSES  w/  LARGE  #  OF  STUDENTS 
SCHEDULE  COURSES  TAUGHT  BY  DEAN/CHAIRMAN 
SCHEDULE  SIMULTANEOUS  SCHEDULED  COURSES 
SCHEDULE  ACCELERATED  COURSES 

SCHEDULE  COURSES  W/  DESIGNATED  STUDENT  COURSE  GRPS 
SCHEDULE  COURSES  REQUIRING  SPECIAL  ROOMS 
SCHEDULE  COURSES  W/  3  HOUR  LABS 
SCHEDULE  COURSES  W/  REQUIRED  LAB  ROOM  AND  TIME 

PERIOD 

SCHEDULE  COURSES  W/  DIVERSITY  OF  MAJORS 
SCHEDULE  COURSES  W/  TEACHING  TEAMS 
SCHEDULE  REMAINING  COURSES 


MODULE  : 

PURPOSE: 


USES: 

RETURNS: 


SCHEDULE  ACCELERATED  COURSES 

To  coordinate  scheduling  of  courses  that  are 
accelerated  courses. 

N/A 

N/A 


FUNCTIONAL  DETAILS: 

Begin 

Loop  until  EOF 

Call  READ  COURSE  FILE  (NULL  STATUS,  ACCELERATED 

COURSE) 

Loop  until  Course  Segment  EOF 

Call  READ  COURSE  SEGMENT  FILE  (COURSE  TYPE, 

COURSE  NUMBER) 

Call  GET  VALID  TIME  PERIOD  AND  ROOM  (COURSE 
SEGMENT  SCREEN  INFO,  SCREEN  INDICATOR) 
Call  RESOLVE  SCHEDULE  RECORD  CONFLICTS  (SCHED 

INFO) 

Call  SAVE  TO  PERTINENT  FILE/RECORD ' (UPDATED 
SCHED  RECORDS,  VALID  TIME  PERIOD, 
NO  OF  SEGMENTS ,  COURSE  TYPE, 
COURSE  NUMBER) 

End  loop 
End  loop 
End 


CALLED  BY:  SCHEDULE  MIDDLE  PRIORITY  COURSES 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


SCHEDULE  COURSES  REQUIRING  SPECIAL  ROOMS 


To  coordinate  scheduling  courses  requiring  special 
rooms  for  instruction. 


N/A 

N/A 


DETAILS : 

Begin 

Loop  until  EOF 

Call  READ  COURSE  FILE  (NULL  STATUS,  SPECIAL 

ROOM  REQUIREMENT) 
Loop  until  Course  Segment  EOF 

Call  READ  COURSE  SEGMENT  FILE  (COURSE  TYPE, 

COURSE  NUMBER) 

Call  GET  VALID  TIME  PERIOD  AND  ROOM  (COURSE 
SEGMENT  SCREEN  INFO,  SCREEN  INDICATOR) 
Call  RESOLVE  SCHEDULE  RECORD  CONFLICTS  (SCHED 

INFO) 

Call  SAVE  TO  PERTINENT  FILE/RECORD  (UPDATED 
SCHED  RECORDS,  VALID  TIME  PERIOD, 
NO  OF  SEGMENTS ,  COURSE  TYPE , 
COURSE  NUMBER) 

End  loop 
End  loop 
End 


CALLED  BY:  SCHEDULE  MIDDLE  PRIORITY  COURSES 


MODULES 


SCHEDULE  COURSES  TAUGHT  BY  DEAN/CHAIRMAN 


PURPOSE : 


USES: 

RETURNS: 


To  coordinate  scheduling  courses  taught  by  a  Dean 
or  Department  Chairman. 

N/A 

N/A 


FUNCTIONAL  DETAILS: 

Begin 

Loop  until  EOF 

Call  READ  INSTRUCTOR  FILE  (DEPT  CHAIR  OR  DEAN) 
Loop  until  Course  Segment  EOF 

Call  READ  COURSE  SEGMENT  FILE  (NULL  STATUS, 

INSTRUC  CODE) 

Call  READ  COURSE  FILE  (COURSE  TYPE,  COURSE 

NUMBER) 

Call  GET  VALID  TIME  PERIOD  AND  ROOM  (COURSE 
SEGMENT  SCREEN  INFO,  SCREEN  INDICATOR) 
Call  RESOLVE  SCHEDULE  RECORD  CONFLICTS  (SCHED 

INFO) 

Call  SAVE  TO  PERTINENT  FILE/RECORD  (UPDATED 
SCHED  RECORDS,  VALID  TIME  PERIOD, 
NO  OF  SEGMENTS,  COURSE  TYPE, 
COURSE  NUMBER) 

End  loop 

If  COURSE  RECORD. SIMULTANEOUS  SCHED  COURSE  not 

null 

Call  UPDATE  SIMULTANEOUS  SCHEDULED  COURSE 

(SIMULTANEOUS  SCHED  COURSE,  VALID  ROOM, 

VALID  TIME  PERIOD) 

Endif 
End  loop 
End 


CALLED  BY:  SCHEDULE  MIDDLE  PRIORITY  COURSES 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


SCHEDULE  COURSES  W/  3  HOUR  LABS 

To  coordinate  scheduling  courses  that  have  3  hour 
laboratories . 

N/A 

N/A 


DETAILS: 

Begin 

Loop  until  EOF 

Call  READ  COURSE  FILE  (NULL  STATUS,  LAB  HRS>/3) 
Loop  until  Course  Segment  EOF 

Call  READ  COURSE  SEGMENT  FILE  (COURSE  TYPE, 

COURSE  NUMBER) 

Call  GET  VALID  TIME  PERIOD  AND  ROOM  (COURSE 
SEGMENT  SCREEN  INFO,  SCREEN  INDICATOR) 
Call  RESOLVE  SCHEDULE  RECORD  CONFLICTS  (SCHED 

INFO) 

Call  SAVE  TO  PERTINENT  FILE/RECORD  (UPDATED 
SCHED  RECORDS,  VALID  TIME  PERIOD, 
NO  OF  SEGMENTS ,  COURSE  TYPE, 
COURSE  NUMBER) 

End  loop 
End  loop 
End 


CALLED  BY:  SCHEDULE  LOWER  PRIORITY  COURSES 


MODULE t  SCHEDULE  COURSES  W/  DESIGNATED  STUDENT  COURSE  GRPS 


PURPOSE:  To  coordinate  scheduling  of  courses  that  have 

designated  Student  Course  Groups. 


USES :  N/A 


RETURNS:  N/A 


FUNCTIONAL  DETAILS: 

Begin 

Loop  until  COURSE  SEGMENT  EOF 

Call  READ  COURSE  SEGMENT  FILE  (NULL  STATUS, 

DES IGNATED  STUDENT  COURSE  GRP ) 
Call  READ  COURSE  FILE  (COURSE  TYPE,  COURSE 

NUMBER) 

Call  GET  VALID  TIME  PERIOD  AND  ROOM  (COURSE 
SEGMENT  SCREEN  INFO,  SCREEN  INDICATOR) 
Call  RESOLVE  SCHEDULE  RECORD  CONFLICTS  (SCHED 

INFO) 

Call  SAVE  TO  PERTINENT  FILE/RECORD  (UPDATED 

SCHED  RECORDS,  VALID  TIME  PERIOD, 
NO  OF  SEGMENTS,  COURSE  TYPE, 
COURSE  NUMBER) 

End  loop 
End 


CALLED  BY:  SCHEDULE  MIDDLE  PRIORITY  COURSES 


MODULE: 

SCHEDULE  COURSES  W/ 

DIVERSITY  OF  MAJORS 

PURPOSE: 

To  coordinate  scheduling  of  courses  that  have  a 
diversity  of  majors  in  its  enrollment. 

USES: 

N/A 

RETURNS: 

N/A 

FUNCTIONAL  DETAILS: 

Begin 

Loop  until  EOF 

Call  READ  COURSE  FILE  (NULL  STATUS,  DIVERSITY 

OF  MAJORS) 

Loop  until  Course  Segment  EOF 

Call  READ  COURSE  SEGMENT  FILE  (COURSE  TYPE, 

COURSE  NUMBER) 

Call  GET  VALID  TIME  PERIOD  AND  ROOM  (COURSE 
SEGMENT  SCREEN  INFO,  SCREEN  INDICATOR) 
Call  RESOLVE  SCHEDULE  RECORD  CONFLICTS  (SCHED 

INFO) 

Call  SAVE  TO  PERTINENT  FILE/RECORD  (UPDATED 
SCHED  RECORDS,  VALID  TIME  PERIOD, 
NO  OF  SEGMENTS,  COURSE  TYPE, 
COURSE  NUMBER) 

End  loop 
End  loop 
End 


CALLED  BY:  SCHEDULE  LOWER  PRIORITY  COURSES 


MODULE 


SCHEDULE  COURSES  W/  LARGE  #  OF  STUDENTS 


PURPOSE: 


USES: 

RETURNS: 


To  coordinate  scheduling  courses  that  have  a  large 
enrollment . 

N/A 

N/A 


FUNCTIONAL  DETAILS: 

Begin 

Loop  until  EOF 

Call  READ  COURSE  SEGMENT  FILE  (NULL  STATUS, 

SEGMENT  STUDENTS) 

Call  READ  COURSE  FILE  (COURSE  TYPE,  COURSE 

NUMBER) 

Call  GET  VALID  TIME  PERIOD  AND  ROOM  (COURSE 

SEGMENT  SCREEN  INFO,  SCREEN  INDICATOR) 
Call  RESOLVE  SCHEDULE  RECORD  CONFLICTS  (SCHED 

INFO) 

Call  SAVE  TO  PERTINENT  FILE/RECORD  (UPDATED 

SCHED  RECORDS,  VALID  TIME  PERIOD, 
NO  OF  SEGMENTS ,  COURSE  TYPE, 
COURSE  NUMBER) 

End  loop 

If  COURSE  RECORD. SIMULTANEOUS  SCHED  COURSE  not 

null 

Call  UPDATE  SIMULTANEOUS  SCHEDULED  COURSE 

(SIMULTANEOUS  SCHED  COURSE,  VALID  ROOM, 

VALID  TIME  PERIOD) 

End  if 
End  loop 
End 


CALLED  BY:  SCHEDULE  TOP  PRIORITY  COURSES 


MODULE: 

SCHEDULE  COURSES  W/  REQUIRED  LAB 
PERIOD 

ROOM  AND  TIME 

PURPOSE: 

To  coordinate  scheduling 
specific  laboratory  at  a 

courses 

specific 

that  require  a 
time. 

USES: 

N/A 

RETURNS: 

N/A 

FUNCTIONAL  DETAILS: 

Begin 

Loop  until  EOF 

Call  READ  COURSE  FILE  (NULL  STATUS,  REQUIRED 

LABROOM) 

Loop  until  Course  Segment  EOF 

Call  READ  COURSE  SEGMENT  FILE  (COURSE  TYPE, 

COURSE  NUMBER) 

Call  GET  VALID  TIME  PERIOD  AND  ROOM  (COURSE 
SEGMENT  SCREEN  INFO,  SCREEN  INDICATOR) 
Call  RESOLVE  SCHEDULE  RECORD  CONFLICTS  (SCHED 

INFO) 

Call  SAVE  TO  PERTINENT  FILE/RECORD  (UPDATED 
SCHED  RECORDS,  VALID  TIME  PERIOD, 
NO  OF  SEGMENTS ,  COURSE  TYPE , 
COURSE  NUMBER) 

End  loop 
End  loop 
End 


CALLED  BY:  SCHEDULE  LOWER  PRIORITY  COURSES 


MODULE  : 

PURPOSE: 

USES: 

RETURNS: 

FUNCTIONAL 


SCHEDULE  COURSES  w/REQUIRED  TIME  PERIOD 

To  schedule  courses  with  required  times  of 
instruction. 

N/A 

N/A 


DETAILS : 

Begin 

Loop  until  EOF 

Call  READ  COURSE  FILE  (NULL  STATUS,  COURSE 

REQUIRED  TIME) 

Loop  until  EOF 

Call  READ  COURSE  SEGMENT  FILE  (COURSE  TYPE, 

COURSENUMBER) 

Call  GET  VALID  TIME  PERIOD  AND  ROOM  (COURSE 
SEGMENT  SCREEN  INFO,  SCREEN  INDICATOR) 
Call  RESOLVE  SCHED  RECORD  CONFLICTS  (SCHED 

INFO) 

Call  SAVE  TO  PERTINENT  FILE/RECORD  (UPDATED 

SCHED  RECORDS ,  COURSE  TYPE, 
COURSE  NUMBER,  VALID  TIME  PERIOD, 

NO  OF  SEGMENTS) 

Endloop 

If  COURSE  RECORD. SIMULTANEOUS  SCHED  COURSE 

not null 

Call  UPDATE  SIMULTANEOUS  SCHEDULED  COURSE 

(SIMULTANEOUS  SCHED  COURSE, 
VALID  ROOM,  VALID  TIME  PERIOD) 

End  if 
Endloop 
End 


CALLED  BY:  SCHEDULE  TOP  PRIORITY  COURSES 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


SCHEDULE  COURSES  w/REQUIRED  TIME  PERIOD  FOR 
INSTRUCTOR 

To  schedule  courses  that  require  Instructor  to 
teach  at  specific  TIME  PERIODS. 

N/A 

N/A 


DETAILS : 

Begin 

Loop  until  EOF 

Call  READ  COURSE  FILE  (NULL  STATUS,  INSTRUC 

REQUIRED  TIME) 

Loop  until  COURSE  SEGMENT  EOF 

Call  READ  COURSE  SEGMENT  FILE  (COURSE  TYPE, 

COURSENUMBER) 

Call  GET  VALID  TIME  PERIOD  AND  ROOM  (COURSE 
SEGMENT  SCREEN  INFO,  SCREEN  INDICATOR) 
Call  RESOLVE  SCHEDULE  RECORD  CONFLICTS  (SCHED 

INFO) 

Call  SAVE  TO  PERTINENT  FILE/RECORD  (UPDATED 

SCHED  RECORDS ,  COURSE  TYPE, 
COURSE  NUMBER, VALID  TIME  PERIOD, 

NO  OF  SEGMENTS) 

End  loop 

If  COURSE  RECORD  SIMULTANEOUS  SCHED  COURSE  no 

null 

Call  UPDATE  SIMULTANEOUS  SCHEDULED  COURSE 

(SIMULTANEOUS  SCHED  COURSE,  VALID 
ROOM,  VALID  TIME  PERIOD) 

End  if 
Endloop 
End 


CALLED  BY:  SCHEDULE  TOP  PRIORITY  COURSES 


MODULE: 


SCHEDULE  COURSES  W/  TEACHING  TEAM 


PURPOSE: 

USES: 

RETURNS: 

FUNCTIONAL 


CALLED  BY: 


To  coordinate  scheduling  courses  that  are  taught  by 
teaching  teams. 

N/A 

N/A 


DETAILS : 

Begin 

Loop  until  COURSE  SEGMENT  EOF 

Call  READ  COURSE  SEGMENT  FILE  (NULL  STATUS, 

TEACHING  TEAM) 

Call  READ  COURSE  FILE  (COURSE  TYPE,  COURSE 

NUMBER) 

Call  GET  VALID  TIME  PERIOD  AND  ROOM  (COURSE 

SEGMENT  SCREEN  INFO,  SCREEN  INDICATOR) 
Call  RESOLVE  SCHEDULE  RECORD  CONFLICTS  (SCHED 

INFO) 

Call  SAVE  TO  PERTINENT  FILE/RECORD  (UPDATED 

SCHED  RECORDS,  VALID  TIME  PERIOD, 
NO  OF  SEGMENTS,  COURSE  TYPE, 
COURSE  NUMBER) 

End  loop 
End 


SCHEDULE  LOWER  PRIORITY  COURSES 


MODULE*  SCHEDULE  LOWER  PRIORITY  COURSES 


PURPOSE*  To  coordinate  the  scheduling  of  lower  priority 
courses . 


USES :  N/A 


RETURNS :  N/A 


FUNCTIONAL  DETAILS: 

Begin 

Call  SCHEDULE  COURSES  W/  3  HOUR  LABS 

Call  SCHEDULE  COURSES  W/  REQUIRED  LAB  ROOM  AND 

TIME  PERIOD 

Call  SCHEDULE  COURSES  W/  DIVERSITY  OF  MAJORS 
Call  SCHEDULE  COURSES  W/  TEACHING  TEAM 
Call  SCHEDULE  REMAINING  COURSES 
End  ■ 


CALLED  BY:  CREATE  NEW  SCHEDULES 


MODULE: 

PURPOSE : 

USES : 

RETURNS: 

FUNCTIONAL 


CALLED  BY: 


SCHEDULE  MIDDLE  PRIORITY  COURSES 

To  coordinate  the  scheduling  of  middle  priority 
courses . 

N/A 

N/A 


DETAILS : 

Begin 

Call  SCHEDULE  COURSES  TAUGHT  BY  DEAN/CHAIRMAN 
Call  SCHEDULE  SIMULTANEOUS  SCHEDULED  COURSES 
Call  SCHEDULE  ACCELERATED  COURSES 
Call  SCHEDULE  COURSES  W/  DESIGNATED  STUDENT 

COURSE  GRPS 

Call  SCHEDULE  COURSES  REQUIRING  SPECIAL  ROOMS 
End 


CREATE  NEW  SCHEDULES 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 


SCHEDULE  REFRESHER  COURSES 

To  schedule  Refresher  Courses. 

N/A 

N/A 


FUNCTIONAL  DETAILS: 

Begin 

Loop 

Call  READ  COURSE  FILE  (NULL  STATUS,  REFRESHER 

COURSE) 

Loop  until  EOF 

Call  READ  COURSE  SEGMENT  FILE  (COURSE  TYPE, 

COURSE  NUMBER) 

Call  GET  VALID  TIME  PERIOD  AND  ROOM  (COURSE 
SEGMENT  SCREEN  INFO,  SCREEN  INDICATOR) 
Call  RESOLVE  SCHEDULE  RECORD  CONFLICTS 

(SCHED  INFO) 

Call  SAVE  TO  PERINTENT  FILE/RECORD  (UPDATED 

SCHED  RECORDS ,  COURSE  TYPE , 
COURSE  NUMBER,  VALID  TIME  PERIOD, 

NO_OF_SEGMENTS ) 

Endloop 

If  COURSE  RECORD. SIMULTANEOUS  SCHED  COURSE 

not  null 

Call  UPDATE  SIMULTANEOUS  SCHEDULED  COURSE 

(SIMULTANEOUS  SCHED  COURSE,  VALID  ROOM, 

VALID  TIME  PERIOD) 

End  if 
End  loop 
End 


CALLED  BY:  SCHEDULE  TOP  PRIORITY  COURSES 


MODULE 


SCHEDULE  REMAINING  COURSES 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


CALLED  BY: 


To  coordinate  the  scheduling  of  courses  that  have 
yet  to  be  scheduled  for  the  academic  quarter. 

N/A 

N/A 


DETAILS : 

Begin 

Loop  until  EOF 

Call  READ  COURSE  FILE  (NULL  STATUS) 

Loop  until  Course  Segment  EOF 

Call  READ  COURSE  SEGMENT  FILE  (COURSE  TYPE, 

COURSE  NUMBER) 

Call  GET  VALID  TIME  PERIOD  AND  ROOM  (COURSE 
SEGMENT  SCREEN  INFO,  SCREEN  INDICATOR) 
Call  RESOLVE  SCHEDULE  RECORD  CONFLICTS  (SCHED 

INFO) 

Call  SAVE  TO  PERTINENT  FILE/RECORD  (UPDATED 
SCHED  RECORDS,  VALID  TIME  PERIOD, 
NO  OF  SEGMENTS,  COURSE  TYPE, 
COURSE  NUMBER) 

End  loop 
End  loop 
End 


SCHEDULE  LOWER  PRIORITY  COURSES 


MODULE: 

PURPOSE : 

USES : 

RETURNS: 

FUNCTIONAL 


SCHEDULE  SEMI -PERM  EVENTS 


To  automatically  schedule  semi -permanent  events. 


N/A 

N/A 


DETAILS : 

Begin 

Loop 

Call  DETERMINE  SEMI -PERM  EVENT  AND  EVENT  MBRSHP 
Call  DETERRMINE  MBRSHP  SCHED  AND  ROOM  SCHED 

(MBRSHP,  ROOM) 

Call  ASSIGN  SEMI -PERM  EVENT  TO  SCHEDULES  (SCHED 
RECORDS,  SEMI -PERM  EVENT  RECORD) 


Endloop 

End 


CALLED  BY: 


CREATE  NEW  SCHEDULE  FILE 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


SCHEDULE  SIMULTANEOUS  SCHEDULED  COURSES 


To  coordinate  scheduling  of  courses  that  must  be 
scheduled  simultaneously  with  other  courses. 


N/A 

N/A 


DETAILS : 

Begin 

Loop  until  EOF 

Call  READ  COURSE  FILE  (NULL  STATUS, 

SIMULTANEOUS  COURSE) 
Loop  until  COURSE  SEGMENT  EOF 

Call  READ  COURSE  SEGMENT  FILE  (COURSE  TYPE, 

COURSE  NUMBER) 

Call  GET  VALID  TIME  PERIOD  AND  ROOM  (COURSE 
SEGMENT  SCREEN  INFO,  SCREEN  INDICATOR) 
Call  RESOLVE  SCHEDULE  RECORD  CONFLICTS  (SCHED 

INFO) 

Call  SAVE  TO  PERTINENT  FILE/RECORD  (UPDATED 

SCHED  RECORDS ,  VALID  TIME 
PERIOD ,  NO  OF  SEGMENTS , 
COURSE  TYPE,  COURSE  NUMBER) 

End  loop 

If  COURSE  RECORD. SIMULTANEOUS  SCHED  COURSE  not 

null 

Call  UPDATE  SIMULTANEOUS  SCHEDULED  COURSE 

(SIMULTANEOUS  SCHED  COURSE,  VALID  ROOM, 

VALID  TIME  PERIOD) 

End  if 
End  loop 
End 


CALLED  BY:  SCHEDULE  MIDDLE  PRIORITY  COURSES 


MODULE: 


SCHEDULE  TOP  PRIORITY  COURSES 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  coordinate  the  scheduling  of  top  priority- 
courses  . 


N/A 

N/A 


DETAILS : 

Begin 

Call  SCHEDULE  REFRESHER  COURSES 
Call  SCHEDULE  COURSES  w/REQUIRED  TIME  PERIOD 
Call  SCHEDULE  COURSES  w/LARGE  ATTENDANCE 
Call  SCHEDULE  COURSES  TAUGHT  BY  DEPT  CHAIR/DEAN 
End 


CALLED  BY 


CREATE  NEW  SCHEDULES 


MODULE  t 

PURPOSE : 

USES: 

RETURNS: 


SCHEDULING  DATA  MAINTENANCE 

To  coordinate  the  maintenance  of  data  files  for  the 
NPS  SCHEDULING  SYSTEM. 

N/A 

N/A 


FUNCTIONAL  DETAILS: 

Begin 

Loop 

Call  GET  VALID  DATA  MAINTENANCE  TRANSACTION 
Case  VALID  TRANSACTION 

When  VALID  TRANSACTION  =  COPY  FILES 
Call  COPY  MAINFRAME  FILES 
When  VALID  TRANSACTION  =  UPDATE 
Call  UPDATE  DATA  FILES 
When  VALID  TRANSACTION  =  PRINT 
Call  PRINT  FILE,  RECORD,  REPORT 
End  Case 
End  loop 
End 


CALLED  BY:  NPS  SCHEDULING  SYSTEM 


MODULE : 

PURPOSE  : 

USES: 

RETURNS: 

FUNCTIONAL 


SEARCH  DATABASE 

To  search  the  database  for  an  ITEM  based  on  the 
ITEM  QUERY. 

ITEM  QUERY 

ITEM 

DETAILS:  (Pre- defined) 

1.  Search  database  for  the  ITEM  matching  the  ITEM 
QUERY . 


CALLED  BY:  VALIDATE  AND  ECHO  PRINT  SCREEN 


module 


SEARCH  FOR  ALTERNATIVES 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


CALLED  BY: 


To  search  the  given  SCHED  RECORDS  for  an 
alternative  TIME  PERIOD  slot  that  has  no  conflict. 

SCHED  RECORDS 


ALTERNATIVES 


DETAILS:  (Pre- defined) 

1.  Search  the  given  SCHED  RECORDS  and  find  all  the 
alternative  TIME  PERIOD  slots,  to  schedule  the 
course,  where  NO  CONFLICT  exists  between  the 
given  SCHED  RECORDS. 

2.  Return  all  TIME  PERIODS  where  INSTRUC  SCHED 
RECORD. TIME  PERIOD  +  ROOM  SCHED  RECORD. TIME 
PERIOD  +  STUDENT  COURSE  GRP. TIME  PERIOD  = 
null . 


RESOLVE  SCHEDULE  RECORD  CONFLICTS 
RESOLVE  UPDATE  CONFLICTS 


MODULE: 


UPDATE  COURSE /COURSE  SEGMENT  FILES 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  update  the  COURSE/COURSE  SEGMENT  FILES  with  data 
from  the  mainframe  E-Z  Class  Demand  List  File. 

N/A 

N/A 


DETAILS : 

Begin 

Loop  until  EOF 

Call  READ  M/F  E-Z  CLASS  DEMAND  LIST  FILE 
Call  READ  M/F  SCG  SECT  FILE  (COURSE  TYPE, 

COURSE  NUMBER) 

Call  WRITE  COURSE  FILE  (COURSE  TYPE,  COURSE 
NUMBER,  LECT  HRS,  LAB  HRS,  SCG  CARD  NUMBER) 
Call  WRITE  COURSE  SEGMENT  FILE  (COURSE  TYPE, 

COURSENUMBER) 

End  loop 
End 


CALLED  BY:  COPY  MAINFRAME  FILES 


MODULE 


UPDATE  COURSE  RECORD 


PURPOSE : 

USES: 

RETURNS : 

FUNCTIONAL 


To  update  the  status  of  a  given  course. 


STATUS 
COURSE  TYPE 
COURSE  NUMBER 


N/A 


DETAILS:  (Pre- defined) 

1.  For  the  given  COURSE  TYPE  and  COURSE  NUMBER, 
update  COURSE  RECORD . STATUS  to  the  given 
STATUS . 


CALLED  BY:  SAVE  TO  PERTINENT  FILE/RECORD 


MODULE : 

PURPOSE : 

USES: 

RETURNS : 

FUNCTIONAL 

CALLED  BY: 


UPDATE  COURSE  SEGMENT  RECORD 

To  UPDATE  the  STATUS,  DAY  and  PERIOD  of  a  given 
COURSE  SEGMENT. 


STATUS 
TIME  PERIOD 
COURSE  TYPE 
COURSE  NUMBER 


N/A 


DETAILS:  ( Pre - defined) 

1.  For  the  given  COURSE  TYPE  and  COURSE  NUMBER, 
update  COURSE  SEGMENT  RECORD . STATUS  with 
STATUS,  COURSE  SEGMENT  RECORD. DAY  with  DAY 
and  COURSE  SEGMENT  RECORD . PERIOD  with  PERIOD. 


SAVE  TO  PERTINENT  FILE/RECORD 


MODULE 


UPDATE  DATABASE  FILES 


PURPOSE:  To  coordinate  the  updating  of  NPS3  database  files. 


USES :  N/A 


RETURNS :  N/A 


FUNCTIONAL  DETAILS: 

Begin 

Loop 

Call  GET  VALID  FILE 

Call  GET  VALID  UPDATE  TRANSACTION 

Case  VALID  TRANSACTION 

When  VALID  TRANSACTION  =  ADD 
Call  ADD  DATA  RECORD 
when  VALID  TRANSACTION  =  MODIFY 
Call  MODIFY  DATA  RECORD 
When  VALID  TRANSACTION  =  DELETE 
Call  DELETE  DATA  RECORD 
End  Case 
End  loop 
End 


CALLED  BY:  SCHEDULING  DATA  MAINTENANCE 


MODULE: 


UPDATE  FACULTY  FILE 


PURPOSE: 

USES: 

RETURNS: 

FUNCTIONAL 


CALLED  BY: 


To  update  the  Faculty  File  with  data  from  the 
mainframe  Professor  Listing  File. 


N/A 

N/A 


DETAILS : 

Begin 

Loop  until  EOF 

Call  READ  M/F  PROFESSOR  LISTING  FILE 

Call  WRITE  FACULTY  FILE  (FACULTY  NAME,  DEPT 

LTR  CODE,  FACULTY  CODE) 

End  loop 
End 


COPY  MAINFRAME  FILES 


MODULE 


UPDATE  SCHEDULE  FILE 


PURPOSE: 

USES: 

RETURNS : 

FUNCTIONAL 


CALLED  BY: 


To  coordinate  updating  an  old  master  schedule  file. 
VALID  FILE 


N/A 


DETAILS : 

Begin 

Loop 

Call  GET  VALID  SCHEDULE  RECORDS  TO  UPDATE 
Call  UPDATE  SCHEDULE  RECORDS  (VALID  SCHED 

RECORDS) 

End  loop 
End 


REVIEW  OLD  SCHEDULE  FILE 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


UPDATE  SCHEDULE  RECORDS 


To  update  schedule  records. 


VALID  SCHED  RECORDS 

N/A 


DETAILS : 

Begin 

Call  GET  DATE 

Call  GET  SCHEDULE  CHANGES 

Call  DETERMINE  CONFLICTS  (SCHED  INFO,  SCHED 

RECORDS ) 

If  SCHEDULE  CONFLICTS  returned 

Call  RESOLVE  UPDATE  CONFLICTS  (SCHED  INFO, 

SCHEDULE  CONFLICT,  SCHED  RECORDS) 
Call  WRITE  TO  FILE  (UPDATED  SCHED  RECORDS) 
Elseif  UPDATED  SCHED  RECORDS  returned 

Call  WRITE  TO  FILE  (UPDATED  SCHED  RECORDS) 
End  if 
End 


CALLED  BY:  UPDATE  SCHEDULE  FILE 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


CALLED  BY: 


UPDATE  SIMULTANEOUS  SCHEDULED  COURSE  RECORD 


To  update  a  simultaneously  scheduled  course  with 
the  VALID  ROOM  and  VALID  TIME  PERIOD. 


SIMULTANEOUS  SCHEDULED  COURSE 

VALID  ROOM 

VALID  TIME  PERIOD 


N/A 


DETAILS:  { Pre - defined) 

1.  For  the  given  simultaneous  scheduled  COURSE 
TYPE  and  COURSE  NUMBER,  update  COURSE  SEGMENT 
RECORD. DAY  with  VALID  DAY,  COURSE  SEGMENT 
RECORD .  PERIOD  with  VALID  PERIOD,  COURSE  SEGMENT 
RECORD . BUILDING  CODE  with  VALID  BUILDING  CODE 
and  COURSE  SEGMENT  RECORD. ROOM  NUMBER  with 
VALID  ROOM  NUMBER. 

2  .  Change  COURSE  SEGMENT  RECORD . STATUS  and  COURSE 
RECORD . STATUS  for  the  given  simultaneous 
scheduled  COURSE  TYPE  and  COURSE  NUMBER  to 
DONE. 


SCHEDULE  REFRESHER  COURSES 

SCHEDULE  COURSES  w/  REQUIRED  TIME  PERIOD 

SCHEDULE  COURSES  w/  REQUIRED  TIME  PERIOD  FOR 

INSTRUCTOR 

SCHEDULE  COURSES  w/  LARGE  NUMBER  OF  STUDENTS 
SCHEDULE  COURSES  TAUGHT  BY  DEAN/CHAIRMAN 
SCHEDULE  SIMULTANEOUS  SCHEDULED  COURSES 


MODULE: 


UPDATE  STUDENT  COURSE  GRP  FILE 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


To  update  the  STUDENT  COURSE  GRP  FILE  with 
data  from  the  mainframe  SECT  file. 


N/A 


N/A 


DETAILS : 

Begin 

Loop  until  EOF 

Call  READ  M/F  SCG  SECT  FILE 

Call  WRITE  SCG  SCHED  FILE  (SECT  SCG  RECORD) 
End  loop 
End 


COPY  MAINFRAME  FILES 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


UPDATE  STUDENT  FILE 

To  update  the  STUDENT  FILE  with  data  from  the 
mainframe  SECT  file. 


N/A 

N/A 


DETAILS : 

Begin 

Loop  until  EOF 

Call  READ  M/F  STUDENT  SECT  FILE 
Call  WRITE  STUDENT  FILE  (SECT  STUDENT 

RECORDS ) 

End  loop 
End 


CALLED  BY:  COPY  MAINFRAME  FILES 


MODULE: 

VALIDATE  AND  ECHO 

COURSE /LAB  SCHEDULING  SCREEN 

PURPOSE : 

To  validate  the  time  period  and  room  entered  by  the 
system  user  for  a  given  course/lab. 

USES: 

N/A 

RETURNS: 

VALID  TIME  PERIOD 
VALID  ROOM 

FUNCTIONAL  DETAILS: 

Begin 

Loop 

Call  READ  SCREEN 
If  FLAG  TYPE  =  QUIT 
Exit  system 
Elseif  FLAG  TYPE=HELP 

Call  DETERMINE  HELP  INSTRUCTIONS  (COURSE/LAB 

SCHEDULING  SCREEN) 


Elseif  FLAG  TYPE  =  RETURN 
GO  TO  previous  menu 
End  if 

Call  GET  TIME  PERIOD 
Call  GET  ROOM 

If  TIME  PERIOD  and  ROOM  are  valid 

Return  (VALID  TIME  PERIOD,  VALID  ROOM) 

Else  Call  PUT  COURSE/LAB  SCHEDULING  SCREEN 
(COURSE/LAB  SCHEDULING  SCREEN,  INVALID  TIME 
PERIOD  MESSAGE  AND/OR  INVALID  ROOM  MESSAGE) 
End  if 
End  Loop 
End 


CALLED  BY:  GET  VALID  TIME  PERIOD  AND  ROOM 


MODULE: 

VALIDATE  AND  ECHO  FILE 

SCREEN 

PURPOSE: 

To  get  a  VALID  FILE  to 

update . 

USES: 

N/A 

RETURNS: 

VALID  FILE 

VALID  FILE  NAME 

FUNCTIONAL 

DETAILS : 

Begin 

Loop 

Call  READ  SCREEN 
If  FLAG  TYPE  =  HELP 

Call  DETERMINE  HELP  INSTRUCTIONS  (FILE 

SCREEN) 

Elseif  FLAG  TYPE  -  QUIT 
Exit  system 

Elseif  FLAG  TYPE  •  RETURN 
GO  TO  previous  menu 
End  if 

Call  GET  FILE  NAME 

When  updating,  reviewing  or  deleting 
Call  READ  FILE  (FILE  NAME) 

If  FILENAME  Exists  as  a  FILE 
Return  (VALID  FILE) 

Else  Call  Put  FILE  SCREEN  (FILE  SCREEN, 

INVALID  FILE  MESSAGE) 

End  if 

When  creating  file 

Return  (VALID  FILE  NAME) 

Exit  loop 
End  loop 
End 


CALLED  BY:  GET  VALID  FILE 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 


VALIDATE  AND  ECHO  PASSWORD  SCREEN 
To  get  a  valid  system  password. 
N/A 

VALID  PASSWORD  (flag) 


FUNCTIONAL  DETAILS: 

Begin 

Count  : =  1 

Loop  while  Count  1=3 
Call  READ  SCREEN 
If  FLAGTYPE  =  HELP 

Call  Determine  HELP  INSTRUCTIONS  (PASSWORD 

SCREEN) 

Elseif  FLAG  TYPE  =  QUIT 
EXIT  SYSTEM 
End  if 

Call  GET  USER  PASSWORD 
Count  =  Count  +  1 
Call  READ  SYSTEM  PASSWORD 
If  SYSTEM  PASSWORD  =  USER  PASSWORD 
Return  VALID  PASSWORD 
Else  Call  Put  PASSWORD  SCREEN  (PASSWORD 

SCREEN,  INVALID  PASSWORD  MESSAGE  1) 

Endif 
End  loop 

Call  PUT  PASSWORD  SCREEN  (PASSWORD  SCREEN, 

INVALID  PASSWORD  MESSAGE  2) 

EXIT  SYSTEM 
End 


CALLED  BY:  GET  VALID  PASSWORD 


MODULE 


VALIDATE  AND  ECHO  PRINT  SCREEN 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


To  get  a  valid  item  to  print 


N/A 

VALID  ITEM 


DETAILS : 

Begin 

Loop 

Call  READ  SCREEN 
IF  FLAG  TYPE  =  HELP 

Call  DETERMINE  HELP  INSTRUCTIONS  (PRINT 

SCREEN) 

Elseif  FLAG  TYPE  =  QUIT 
Exit  system 

Elseif  FLAG  TYPE  =  RETURN 
GO  TO  previous  menu 
Endif 

Call  GET  ITEM  PRINT  QUERY 

Call  SEARCH  DATABASE  (ITEM  QUERY) 

If  ITEM  exists  for  ITEM  QUERY 
Return  VALID  ITEM 

Else  Call  PUT  FILE  SCREEN  (FILE  SCREEN, 

INVALID  FILE  MESSAGE) 

Endif 
End  loop 
End 


CALLED  BY:  GET  VALID  ITEM  TO  PRINT 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


CALLED  BY: 


VALIDATE  AND  ECHO  SCHEDULE  CONFLICT/ALTERNATIVES 

SCREEN 


To  validate  the  alternative  TIME  PERIOD  selected  by 
the  system  user  for  a  given  SCHEDULE  CONFLICT. 

N/A 

VALID  ALTERNATIVE  SELECTION 


DETAILS : 

Begin 

Loop 

Call  READ  SCREEN 
If  FLAG  TYPE  =  QUIT 
Exit  system 

Elseif  FLAG  TYPE  =  HELP 

Call  DETERMINE  HELP  INSTRUCTIONS  (SCHEDULE 

CONFLICT/ALTERNATIVES 

SCREEN) 

Elseif  FLAG  TYPE  =  RETURN 
GO  TO  previous  menu 
Endif 

Call  GET  ALTERNATIVE  SELECTION 
If  ALTERNATIVE  SELECTION  is  VALID 

Return  (VALID  ALTERNATIVE  SELECTION) 

Else  Call  PUT  SCHEDULE  CONLICT/ ALTERNATIVES 

SCREEN  (SCHEDULE  CONFLICT/ALTERNATIVES 
SCREEN,  INVALID  SELECTION  MESSAGE) 

Endif 

Endloop 

End 


RESOLVE  SCHEDULE  RECORD  CONFLICT 
RESOLVE  UPDATE  CONFLICTS 


MODULES  VALIDATE  AND  ECHO  SCHEDULE  RECORD  SCREEN 


PURPOSE:  To  coordinate  getting  VALID  SCHED  RECORDS  to 

update. 


USES :  N/A 


RETURNS:  VALID  SCHED  RECORDS 


FUNCTIONAL  DETAILS: 

Begin 

Loop 

Call  READ  SCREEN 
IF  FLAG  TYPE  =  HELP 

Call  DETERMINE  HELP  INSTRUCTIONS  (SCHEDULE 

RECORD  SCREEN) 

Elseif  FLAG  TYPE  =  QUIT 
Exit  system 

Elseif  FLAG  TYPE  =  RETURN 
GO  TO  previous  menu 
Endif 

Call  GET  SCHEDULE  RECORD  QUERY 

Call  READ  SCHED  RECORDS  (SCHEDULE  RECORD  QUERY) 

If  SCHED  RECORDS  exist 

Return  VALID  SCHED  RECORDS 
Elseif  NOT  FOUND  returned 

Call  PUT  SCHEDULE  RECORD  SCREEN  (SCHEDULE 

RECORD  SCREEN, 
INVALID  SCHEDULE  RECORD  MESSAGE) 

End  if 
End  loop 
End 


CALLED  BY:  GET  VALID  SCHEDULE  RECORDS  TO  UPDATE 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 


VALIDATE  AND  ECHO  TRANSACTION  SCREEN 
To  get  a  valid  transaction. 

N/A 

VALID  TRANSACTION 


FUNCTIONAL  DETAILS: 

Begin 

Loop 

Call  READ  SCREEN 
If  FLAG  TYPE  =  HELP 

Call  DETERMINE  HELP  INSTRUCTIONS  (TRANSACTION 

SCREEN) 

Elseif  FLAG  TYPE  =  QUIT 
Exit  system 

Elseif  FLAG  TYPE  =  RETURN 
GO  TO  previous  menu 
Endif 

Call  GET  TRANSACTION 

If  TRANSACTION  is  a  VALID  TRANSACTION 
Return  VALID  TRANSACTION 
Else  Call  PUT  TRANSACTION  SCREEN  (TRANSACTION 
SCREEN,  INVALID  TRANSACTION  MESSAGE) 

Endif 
End  loop 
End 


CALLED  BY:  GET  VALID  NPS  SCHEDULING  SYSTEM  TRANSACTION 
GET  VALID  DATA  MAINTENANCE  TRANSACTION 
GET  VALID  FILE  UPDATE  TRANSACTION 
GET  VALID  EVENT/COURSE  TRANSACTION 


MODULE: 


PURPOSE: 


USES: 


RETURNS: 


FUNCTIONAL 


WRITE  COURSE  FILE 


To  write  a  Course  file  for  the  NPS3  from  the  E-Z 
Class  Demand  List  File  and  the  SCG  SECT  File. 


COURSE  TYPE 
COURSE  NUMBER 
LECT  HRS 
LAB  HRS 

SCG  CARD  NUMBER 


N/A 


DETAILS:  ( Pre -  defined) 

1.  Write  the  course  information  to  Course  File. 


CALLED  BY:  UPDATE  COURSE/COURSE  SEGMENT  FILES 


MODULE:  WRITE  COURSE  SEGMENT  FILE 

PURPOSE:  To  write  a  Course  Segment  File  for  the  NPS3  from 

the  E-Z  Class  Demand  List  File. 

USES :  COURSE  TYPE 

COURSE  NUMBER 

RETURNS :  N/A 

FUNCTIONAL  DETAILS:  (Pre- defined) 

1.  Write  the  course  information  to  Course  Segment 
File. 

CALLED  BY:  UPDATE  COURSE/COURSE  SEGMENT  FILES 


MODULE:  WRITE  FACULTY  FILE 

PURPOSE:  To  write  a  FACULTY  FILE  for  the  NPS3  from  the 

Professor  Listing  File. 

USES :  FACULTY  NAME 

FACULTY  CODE 
DEPT  LTR  CODE 

RETURNS :  N/A 

FUNCTIONAL  DETAILS:  ( Pre - defined) 

1.  Write  the  Faculty  information  to  FACULTY  FILE. 

CALLED  BY:  UPDATE  FACULTY  FILE 


MODULE : 


WRITE  INSTRUC  SCHED  FILE 


PURPOSE  : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


To  write  the  UPDATED  INSTRUC  SCHED  RECORD  to  the 
INSTRUC  SCHED  FILE. 


UPDATED  INSTRUC  SCHED  RECORD 
DATE 


N/A 


DETAILS:  (Pre- defined) 

1.  Write  the  UPDATED  INSTRUC  SCHED  RECORD  to  the 
INSTRUC  SCHED  FILE. 


ASSIGN  SEMI -PERM  EVENT  TO  SCHEDULES 
SAVE  TO  PERTINENT  FILE/RECORD 


MODULE : 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


WRITE  MASTER  SCHEDULE  FILE 

To  write  the  SCHED  RECORDS  to  a  master  schedule 
file. 


VALID  FILE  NAME 
SCHED  RECORDS 

N/A 

DETAILS:  (Pre- defined) 

1.  Write  all  SCHED  RECORDS  to  the  designated  named 
file. 


CALLED  BY:  SAVE  TO  MASTER  SCHEDULE  FILE 


MODULE:  WRITE  NPS3  SCG  SCHED  FILE 

PURPOSE:  To  write  a  SCG  SCHED  FILE  for  the  NPS3  from  SECT 

SCG  RECORDS. 

USES:  SECT  SCG  RECORD 

RETURNS :  N/A 

FUNCTIONAL  DETAILS:  (Pre- defined) 

1.  write  the  SECT  SCG  RECORD  to  the  NPS3  SCG 
SCHED  FILE. 

CALLED  BY:  UPDATE  STUDENT  COURSE  GROUP  FILE 


MODULE: 


WRITE  ROOM  SCHED  FILE 


PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


To  write  the  UPDATED  ROOM  SCHED  RECORD  to  the  ROOM 
SCHED  FILE. 


UPDATED  ROOM  SCHED  RECORD 
DATE 


N/A 


DETAILS:  (Pre- defined) 

1.  Write  the  UPDATED  ROOM  SCHED  RECORD  to  the  ROOM 
SCHED  FILE. 


ASSIGN  SEMI -PERM  EVENT  TO  SCHEDULES 
SAVE  TO  PERTINENT  FILE/RECORD 


MODULE  J 


WRITE  SCG  SCHED  FILE 


PURPOSE t 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


To  write  the  UPDATED  SCG  SCHED  RECORD  to  the  SCG 
SCHED  FILE. 


UPDATED  SCG  SCHED  RECORD 
DATE 

N/A 

DETAILS:  (Pre- defined) 

1.  Write  the  UPDATED  SCG  SCHED  RECORD  to  the  SCG 
SCHED  FILE. 


ASSIGN  SEMI -PERM  EVENT  TO  SCHEDULES 
SAVE  TO  PERTINENT  FILE/RECORD 


MODULE : 


WRITE  STUDENT  FILE 


PURPOSE: 

USES: 

RETURNS: 

FUNCTIONAL 

CALLED  BY: 


To  write  a  STUDENT  FILE  for  the  NPS3  from  SECT 
STUDENT  RECORDS. 

SECT  STUDENT  RECORDS 

N/A 

DETAILS:  (Pre- defined) 

1.  Write  the  SECT  RECORD  to  the  STUDENT  FILE. 

UPDATE  STUDENT  FILE 


MODULE: 

PURPOSE : 

USES: 

RETURNS: 

FUNCTIONAL 


WRITE  TO  FILE 

To  write  the  UPDATED  SCHED  RECORDS  to  the  file 
being  updated. 


UPDATED  SCHED  RECORDS 
N/A 

DETAILS:  (Pre-def ined) 

1.  Write  the  UPDATED  SCHED  RECORDS  to  the  master 
schedule  file  being  updated. 


CALLED  BY:  UPDATE  SCHEDULE  RECORDS 
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